Subject: [Geopriv] Revised draft-ietf-geopriv-dhcp-civil

From: Ralph Droms <[email-masked]>
Date: Wed, 27 Jul 2005 17:21:37 -0400

I see that draft-ietf-geopriv-dhcp-civil-06.txt is different from the
revision that the dhc WG reviewed last October.  Please don't take any
final action on this document until the dhc WG has had a chance to
review the revised document.

- Ralph

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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 27 Jul 2005 15:02:50 -0700

Ralph,
	The document is still under IESG review to resolve a DISCUSS
comment by David Kessens.  Please be aware, though, that the major
change was in reaction to your last call comment on the draft, that it
needed to make clear whether the mechanism was to be implemented
as downstream only.  The added text there is:

   This document only defines the delivery of location information from
   the DHCP server to the client, due to security concerns related to
   using DHCP to update the database.

	Other changes, relating to the inclusion of postal community
name and "additional code",  should have no bearing on the dhc
aspects of this draft.   I believe if you check the diff at http://bgp.potaroo.net/cgi-bin/htmlwdiff?f1=%2e%2e%2fall%2dids%2fdraft%2dietf%2dgeopriv%2ddhcp%2dcivil%2d06%2etxt&f2=%2e%2e%2fall%2dids%2fdraft%2dietf%2dgeopriv%2ddhcp%2dcivil%2d05%2etxt

you'll see fairly quickly that this is the case.  While your additional
review is, of course, welcome, this document is already behind its schedule
and  we need to avoid further delay.
				regards,
					Ted Hardie

---

From: Ralph Droms <[email-masked]>
Date: Thu, 28 Jul 2005 07:47:02 -0400

Ted - But my comment about the draft gave a preference for allowing
transmission of location information in both directions.  From
http://www1.ietf.org/mail-archive/web/geopriv/current/msg00658.html

  "My personal preference would be to allow both the host and the server
   to send the option to the other DHCP message partner.  I can imagine
   situations in which a host has explicit knowledge of its location
   that it would want to send to the server."

In a followup message, Henning also saw utility in transmitting the
information in both directions
http://www1.ietf.org/mail-archive/web/geopriv/current/msg00659.html

  "I agree that both directions are useful, although the direction from
   host to server might necessitate the inclusion of the core privacy
   elements into the object (distribution, retention)."

I'm curious about the reason for the eventual text proscribing the
delivery of location information from the DHCP client to the server.  I
can't find any discussion of security concerns in the geopriv mailing
list archives.   The minutes of the interim geoloc meeting in May
mentions only

  "Jon Peterson expressed concern that this would then lead to sending
   location information to unauthenticated entities."

Is Jon's concern the basis for the "security concerns related to using
DHCP to update the database"?

Also, it appears I was misrepresented at the geopriv interim meeting.
>From the minutes:

  "Ted Hardie clarified the comment by Ralph Drums during last call,
   noting that the last call comment noted that DHCP communications
   happen both ways at multiple times and that
   draft-ietf-geopriv-dhc-civic needed to clarify the meaning of the
   communication at certain time but not that location information
   should be sent from a DHCP client to a DHCP server."

In my e-mail (I actually didn't send it until some time after the last
call when I realized that the location information should travel in both
directions), I did suggest that a clarification was needed.  But I
expressed a preference that information should, indeed, be allowed from
the DHCP client to the server.

I note that the new text is in the Introduction, rather than in the more
normative Security Considerations section along with the other advice
about the use of this option.

It would be more in keeping with the design principles of DHCP to be a
mechanism rather than impose a policy to describe explicitly the
security concerns associated with the delivery of location information
from the DHCP client to the server, and to allow administrators to make
their own decision about whether or not to make use of this option in
that way.

Had the dhc WG been explicitly informed of the revs to the document and
asked to review the document when the changes were made, we could have
resolved this issue at that time.

- Ralph

---

From: Ted Hardie <[email-masked]>
Date: Thu, 28 Jul 2005 10:15:47 -0700

>   that it would want to send to the server."

I understand your comment gave a preference.  As it stands, however,
the GEOPRIV working group has an established privacy context which
strongly conditions this communication.  The original dhcp mechanism
was approved as providing input into a a host's knowledge of its
location (as "location information" or li in GeoPRIV terms).  It was
explicitly exempted from GeoPRIV's privacy aspects because it
was carrying information that was then used to create a location
object (or lo in GeoPRIV terms), which would be part of the normal
privacy context. Both this document and that document failed to make
clear whether it could also be used to provide location information
from a host to the DHCP server; in considering that question the
conclusion I heard the WG reach was that there was no compelling use case
for Location Information going from the host to the dhcp server.
The use cases presented all turned out to be cases where the information
was then sent on to other servers or used for non-configuration purposes;
those require location objects in GeoPRIV's architecture, and re-using a
mechanism that does not provide  for that privacy was deemed inappropriate.

If there is a use case for the host's sharing its knowledge of its location
with a dhcp server so that the dhcp server can use it to configure the
host, please do share it.  It needs to be fairly compelling though, but
it is clearly the case that passing this data without privacy guards opens
up the very issues that GeoPRIV was designed to address.

>   elements into the object (distribution, retention)."

I believe this comment was given before the interim meeting at which this
was discussed.

>DHCP to update the database"?

It is not just Jon's concern, but, yes, this an aspect of this problem.

>the DHCP client to the server.

I am sorry if I misrepresented you, but I understood your comment to
have two parts:  highlighting an ambiguity in the specification, which is a last
call comment that the WG had to address, and a preference for how to
address it.  This was taken into account by the WG, but the privacy context
concerns were held to be primary.

To clarify this:  Is the specification that the WG has now made *a* correct
choice according to the DHC specification? 

>about the use of this option.

It was seen as important to set context .  If you believe that it also belongs in the Security Considerations, I don't believe there is a harm in repeating it, so
I'd ask anyone in the GeoPRIV WG who has a problem with it being repeated
to say so now.  If there are no objections, we can add it with an RFC Editor note.

>their own decision about whether or not to make use of this option in

The design principles of GeoPRIV, as I noted above, say that locations
should normally be passed as location objects so that the privacy context
may be retained.  Location information used to populate location objects
is a compelling special case, and one that DHCP "downstream" was held to fit. 
The policy mechanisms for other client to server communications are those
already put in place by GeoPRIV.

>resolved this issue at that time.

We understood from your earlier comments that this one acceptable resolution
according to the DHC specs, even if it is not your preference; in your review,
please confirm whether or not this is the case.  Discussion of whether this is
the right choice needs to take place on the GEOPRIV mailing list, as the privacy
context aspects are a central part of its chartered  work.

			regards,
				Ted Hardie

---

From: John Schnizlein <[email-masked]>
Date: Thu, 28 Jul 2005 13:44:15 -0400

This is the first time I have seen the Internet principle that use 
cases must be specified in order to use an existing Internet protocol 
as normally intended.  When was the design goal of mechanism rather 
than policy in protocols reversed?

Where is the list of "all use cases" to which you refer?

There is nothing in permitting the DHCP option to be carried in any 
DHCP message that implies that the information would be sent on to 
other servers.  At the point when transferring this information to 
other server is proposed, it seems to me there would be a valid concern 
to show how the user's privacy is protected.

John

On Jul 28, 2005, at 1:15 PM, Ted Hardie wrote:

> Both this document and that document failed to make

---

From: John Schnizlein <[email-masked]>
Date: Thu, 28 Jul 2005 13:54:20 -0400

> up the very issues that GeoPRIV was designed to address.

It is not at all clear that allowing a host to send its location to the 
DHCP server opens any privacy issues.  Requiring hosts to send their 
locations would raise questions about the purpose of the requirement 
(not needed for correct protocol operation), but nobody has proposed 
that.

The DHCP server might use the location information learned from host A 
to tell host B the location of the ethernet jack used by host A.  No 
user information is involved in this use of the DHCP protocol.  No 
privacy issues are raised.

It is the DHC WG that could be expected to understand the operation of 
DHCP.  If necessary, they could have educated the GeoPriv WG about 
this.

John

---

From: Ted Hardie <[email-masked]>
Date: Thu, 28 Jul 2005 11:04:15 -0700

At 1:44 PM -0400 7/28/05, John Schnizlein wrote:
>This is the first time I have seen the Internet principle that use cases must be specified in order to use an existing Internet protocol as normally intended.  When was the design goal of mechanism rather than policy in protocols reversed?

If you consider "privacy" to be a policy goal, it is set out in the GeoPRIV charter.
For your convenience, here is the text:

>As more and more resources become available on the Internet, some
>applications need to acquire geographic location information about
>certain resources or entities. These applications include navigation,
>emergency services, management of equipment in the field, and other
>location-based services.
>
>But while the formatting and transfer of such information is in some
>sense a straightforward process, the implications of doing it,
>especially in regards to privacy and security, are anything but.
>
>The primary task of this working group will be to assess the the
>authorization, integrity and privacy requirements that must be met in
>order to transfer such information, or authorize the release or
>representation of such information through an agent.
>
>In addition, the working group will select an already standardized
>format to recommend for use in representing location per se.  A key
>task will be to enhance this format and protocol approaches using the
>enhanced format, to ensure that the security and privacy methods are
>available to diverse location-aware applications.  Approaches to be
>considered will include (among others) data formats incorporating
>fields directing the privacy handling of the location information and
>possible methods of specifying variable precision of location.
>
>Also to be considered will be:  authorization of requestors and
>responders; authorization of proxies (for instance, the ability to
>authorize a carrier to reveal what timezone one is in, but not what
>city.  An approach to the taxonomy of requestors, as well as to the
>resolution or precision of information given them, will be part of this
>deliverable.
>
>The combination of these elements should provide a service capable of
>transferring geographic location information in a private and secure
>fashion (including the option of denying transfer).
>
>For reasons of both future interoperability and assurance of the
>security and privacy goals, it is a goal of the working group to
>deliver a specification that has broad applicablity and will become
>mandatory to implement for IETF protocols that are location-aware.

>Where is the list of "all use cases" to which you refer?

I'd suggest starting with RFCs 3693 and 3694.

>There is nothing in permitting the DHCP option to be carried in any DHCP message that implies that the information would be sent on to other servers.  At the point when transferring this information to other server is proposed, it seems to me there would be a valid concern to show how the user's privacy is protected.

Is there any reason for the DHCP server to receive this data, other than passing it to
another server?  Why specify something if it's a no-op, when passing it has privacy
implications for eavesdropping, if nothing else?

				regards,
					Ted Hardie

---

From: John Schnizlein <[email-masked]>
Date: Thu, 28 Jul 2005 14:04:56 -0400

On Jul 28, 2005, at 1:15 PM, Ted Hardie wrote:
> It was seen as important to set context .  If you believe that it also 
> belongs in the Security Considerations, I don't believe there is a 
> harm in repeating it, so

Repeating nonspecific "security concerns" is not helpful.  The reason 
that security considerations are supposed to be in this section is to 
facilitate review by the Security Area.  Security Area reviewers have 
been quite good about requesting the specifics of a "security concern" 
so that they can evaluate the risks.

The text being discussed is the following, which might be interpreted 
to imply that the security concerns for an option in a DHCP-request 
message are different from those in a DHCP-offer message:
    This document only defines the delivery of location information from
    the DHCP server to the client, due to security concerns related to
    using DHCP to update the database.

The DHC WG is competent to evaluate the truth value of that implication.

  John

---

From: John Schnizlein <[email-masked]>
Date: Thu, 28 Jul 2005 14:32:50 -0400

> If you consider "privacy" to be a policy goal, it is set out in the 

While privacy is a valid goal, pursuing Internet protocols that enable 
preserving privacy is not the same as reversing the concept that 
protocol elements provide mechanisms rather than enforce policy.  The 
broad understanding is that, since protocols are incapable of enforcing 
policy, policy must be applied by the hosts.

Is the implied principle that a practical use case must be identified 
before allowing a protocol element in a protocol message specified 
anywhere? I honestly have not seen it.

> For your convenience, here is the text:

[gratuitous long quote deleted]

> I'd suggest starting with RFCs 3693 and 3694.

As you suggested, I have reviewed both RFCs.  Neither one lists any use 
cases of the sort that you mentioned:

On Jul 28, 2005, at 1:15 PM, Ted Hardie wrote:
>
> I heard the WG reach was that there was no compelling use case

The question remains: where are the use cases "for location information 
going from the host to the DHCP server", which you claim were 
presented?

>> other server is proposed, it seems to me there would be a valid 
>> concern to show how the user's privacy is protected.
>

Just because you cannot imagine a good use for a protocol operation 
that is consistent with the design of the protocol does not mean that 
you should prohibit (inasmuch as the IETF could prohibit anything) it.  
Presuming a purpose at odds with the intention of GeoPriv appears to be 
reasoning in bad faith.  The point where a valid concern would arise 
would be IF a protocol were proposed for passing on the location 
information.

John

---

From: Andrew Newton <[email-masked]>
Date: Thu, 28 Jul 2005 15:24:11 -0400

On Jul 28, 2005, at 2:32 PM, John Schnizlein wrote:

> The broad understanding is that, since protocols are incapable of  
> enforcing policy, policy must be applied by the hosts.

Are you advocating that these dhcp options be updated to include the  
retention and distribution privacy options?  Otherwise, how will the  
hosts be able to properly apply these privacy policies?

-andy

---

From: John Schnizlein <[email-masked]>
Date: Thu, 28 Jul 2005 17:21:27 -0400

> hosts be able to properly apply these privacy policies?

Of course not!  You removed my statement from its context.

There is no privacy issue to worry about when a host that has attached 
to an ethernet jack includes its location in the DHCP message that is 
part of its initial configuration.

Since this configuration of a host often happens as part of 
boot-strapping the host, any privacy polity associated with the user of 
that host will often not even be available at that point.

The supposition that the DHCP server would be publishing the location 
information, which seems to underlie the privacy concerns has no basis. 
  If a protocol were specified for the DHCP server to provide the 
information to others, that protocol would be a proper focus of this 
concern.  For example, we could consider a proposal that a HELD system 
have access to the DHCP servers within the access network's 
administration so that it could provide locations under the privacy 
constraints defined in HELD.  As it is now, it is unclear how a 
Location Server in the HELD system learns the locations associated with 
IP addresses.

The point here is that a new principle, demanding a use case be 
identified to allow the DHCP option to be included in different DHCP 
messages, is being asserted as higher precedence than the principle of 
mechanism rather than policy in the design of DHCP.

John

---

From: Ted Hardie <[email-masked]>
Date: Thu, 28 Jul 2005 15:43:35 -0700

At 1:54 PM -0400 7/28/05, John Schnizlein wrote:
>The DHCP server might use the location information learned from host A to tell host B the location of the ethernet jack used by host A.  No user information is involved in this use of the DHCP protocol.  No privacy issues are raised.

John,
	If you really mean it will tell host B the location of the ethernet jack
used by host A, then yes, of course there are privacy concerns.  If what you
mean is that it will derive a location for host B's ethernet jack from what
host A told it, then you could argue that this is location information being
used to derive location information, with no reason for it to be treated as
a location object.  But the working group discussed this point, and it saw
several problems.  The first was that there was no way without using an
LO to limit the information provided to this use case.  Once the DHCP
server has the information, shorn of the privacy aspects encoded in an LO,
the uses it puts it to are out of the control of user; that's the whole problem
the PRIV in geopriv is meant to prevent.  The second problem was that
there was no obvious way to guarantee that the information provided at
jack A was valid.  If jack A provides bogus data that the DHCP server then
provides B, all of the LOs that B's host derives from it will be invalid.  Given
the types of services that these may be used with, that's a very serious concern.
(Note that this is not even necessarily the result of an attack; it could be the
result of bad data coming from a different interface.).  The loss of privacy
to eavesdropping was a third issue discussed; this is, of course, more likely in WiFi
or similar environments than modern wired ethernet.
	I'm afraid my prep for leaving has reached a point where I'll probably
not be able to respond further before Paris, but hopefully we can get a chance
to discuss this there.
			regards,
					Ted Hardie

---

From: John Schnizlein <[email-masked]>
Date: Thu, 28 Jul 2005 19:19:39 -0400

I do not know why this is being made so difficult.

If the location of the ethernet jack can be located by host A when it 
is plugged in there, the normal ability of DHCP messages to carry an 
option either to or from the server enables it to provide the location 
of the jack to the DHCP server.  Any host B that subsequently plugs 
into that jack can then be given its location.

Because host A is clearly not plugged into the jack when host B is, the 
privacy of the location of host A is not at risk.

Raising irrelevant concerns about bogus locations from host A, or from 
any other part of any system that provides location information is not 
clarifying this situation.

On Jul 28, 2005, at 6:43 PM, Ted Hardie wrote:

>> The DHCP server might use the location information learned from host 
>> A to tell host B the location of the ethernet jack used by host A.  
>> No user information is involved in this use of the DHCP protocol.  No 
> a location object.

I do not understand what sort of derivation is called for.  When host A 
used the ethernet jack in question, it located itself at that jack.  
When host B subsequently uses the same jack at that location, it is at 
that location.  Is the argument about the length of the drop cable?

>  But the working group discussed this point, and it saw
> LO to limit the information provided to this use case.

There is no need to limit the information.  Nobody's privacy is 
threatened.  There is no reason to think that host A is there when host 
B is there.  This is not due to any policy mechanism, it is physical 
reality.

>   Once the DHCP

Evocative phrasing aside, the information the DHCP server has after 
host A sends the location-information option is the location of the 
ethernet jack.  No shearing is involved.

> the PRIV in geopriv is meant to prevent.

I do not understand the fear of "the uses [the DHCP server] puts to the 
location of the ethernet jack that may be used by some other host at 
some other time.  How sinister is it that the DHCP server, having 
learned the location through the location-information option tells the 
next host that is attached through that jack the location it knows.

> The second problem was that

Bogus data is a risk for every approach to location information.  Why 
do you associate this risk with one direction of DHCP message transfer?

> not be able to respond further before Paris, but hopefully we can get 

Thank you for the offer.

John

---

From: Andrew Newton <[email-masked]>
Date: Fri, 29 Jul 2005 05:13:16 -0400

> Of course not!  You removed my statement from its context.

Sorry.  I did not intend to do that.  But I was confused about what  
it is you want changed in the draft.

> There is no privacy issue to worry about when a host that has  
> attached to an ethernet jack includes its location in the DHCP  
> message that is part of its initial configuration.

Why isn't there?  If my location-aware device knows my location and  
it is sending that information to anybody else, then I should be able  
to attach my privacy preferences to it.  If I'm sending that to the  
DHCP server, I should have the right to also say that it should not  
pass on that information.

> Since this configuration of a host often happens as part of boot- 
> strapping the host, any privacy polity associated with the user of  

Perhaps if the host is an old Sparc 5 or something, but it is very  
common today to have hosts that are fully booted by the time they  
attach to any network.  It is quite common these days to wonder from  
network to network with a fully booted host.  There is no reason to  
assume that it does not already have privacy policy pre-configured.

> The supposition that the DHCP server would be publishing the  
> location information, which seems to underlie the privacy concerns  
> has no basis.  If a protocol were specified for the DHCP server to  
> provide the information to others, that protocol would be a proper  
> focus of this concern.  For example, we could consider a proposal  
> that a HELD system have access to the DHCP servers within the  
> access network's administration so that it could provide locations  
> under the privacy constraints defined in HELD.  As it is now, it is  
> unclear how a Location Server in the HELD system learns the  
> locations associated with IP addresses.

Lack of a known or formalized publication protocol on the DCHP server  
does not obviate the need privacy concerns.

> identified to allow the DHCP option to be included in different  
> DHCP messages, is being asserted as higher precedence than the  
> principle of mechanism rather than policy in the design of DHCP.

I do not understand this.  But I do think it is good practice to know  
why something is being done.  And in general, just because we CAN do  
something doesn't mean we SHOULD do it.

-andy