Subject: [Geopriv] Re: [dhcwg] Re: I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Nov 2005 19:51:46 -0500

Bernie Volz (volz) wrote:
> Henning:
> 
> I assume this default "do not distribute" policy applies for either
> direction (client to server (server should not distribute) and server to
> client (client should not distribute)) or do you propose to have this
> apply only when the client sends it to the server?

There is a crucial difference, as John Schnitzlein pointed out: The DHCP 
server is telling the client where it is, which the client is presumably 
is free to share with whomever it likes. ("It's *my* location and I'll 
do what I want with it.") I'm ignoring the case here of the abductee 
case where the kidnap victim is told that if he reveals his location, 
he'll be shot. I don't think we need to support this particular kind of 
enforced location privacy and I doubt that RFC injunctions would be 
particularly effective in this case.

If the client tells the server where it is, the client is telling a 
third party something that has potential privacy implications. Just 
because I'm telling Verizon where my 802.16 wireless modem is located so 
that it can help with 911 calls or dispatch a repair truck doesn't mean 
that I'd like Verizon to sell or give this information to the world at 
large. In PIDF-LO, there is a basic privacy indicator that allows me to 
make a choice ("keep this to yourself"); this is not currently in the 
geo or civic DHCP options. Thus, the suggestion for a privacy-friendly 
default policy.

> 
> If this policy doesn't apply when from server to client (what the I-D
> currently allows), what policy does apply to the information the client
> receives as this privacy information isn't communicated? And, thus isn't
> this be a flaw in the current document that should be addressed
> (irrespective of the issue I raised below).

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

---

From: Ted Hardie <[email-masked]>
Date: Fri, 18 Nov 2005 15:36:27 -0800

Because of a family medical issue, I've been unable to follow the list for the past
week or so.  Sorry to revive the thread, but I want us to be clear about the
proposals on the table.  I've tried to summarize them in a brief way below.

>From Andy:

We treat DHCP server-to-client as a sighting function.  That makes the information
sent  "location information" under GeoPriv terms, which is exempt from the
GeoPriv privacy considerations because of the problems with application of
the rules before it is possible to construct a location object.    We do not
treat DHCP client-to-server as a sighting function (since the location is
the client's, not the servers), and so the location passed is subject to
GeoPriv privacy concerns.  Since DHCP is not carrying PIDF-LO,  it
should not carry anything, and the client-to-server direction should be
ruled out.

>From Bernie:

The client-to-server direction should not be ruled out, but its use should
be restricted by the Security Considerations set out in GeoPriv documents.
He points in particular to RFC 3694 (I believe to the Protocol Attacks in 4.1). 

He believes that this puts the use of the information passed client-to-server
under the administrative policy control of the server:

>For (2), this depends on if and how the server uses the received
>information. And, that is up to the administrative policies on the
>server.

>From Henning:

Let's not make it a MUST NOT, but instead indicate that the default permission
for anything sent from client-to-server is "do not distribute".   Since the client's
sending it indicates permission for the server to have it, this restricts the
communication from going anywhere else.  This is a compromise position
to accomplish the two perceived goals:  it should not be a protocol error,
but the information should be restricted.

I hope this captures, in brief, the basic positions.  If I have gotten any of
these wrong, please correct me.

In general, I support Henning's proposed compromise, but I am concerned that
some supporting it may not recognize the full implications.  Reading RFC 3694,
as Bernie suggests, is important to digging those out.  My reading is that
with a default of "do no distribute" and no other way within the client-to-server
exchange to indicate a non-default set of rules, there is no way that the information
can move beyond the DHC server to any other server  (Server here does not mean
box; it means any other function, even if it is within the same administrative
domain or resident in the same box).  According to RFC 3694's model,
changing that default is not within the policy control of the server--it is
a function of the rule maker (see section 6).  The DHC client would be the
rule maker here.    If I have misunderstood, and we agree that this is the
case, then I believe a short of RFC Editor note can be added (or a quick
respin done).
			regards,
				Ted Hardie

At 8:01 PM -0500 11/14/05, Bernie Volz \(volz\) wrote:
>I'm find with this restriction.
>
>- Bernie
>
>> -----Original Message-----
>> From: Henning Schulzrinne [mailto:[email-masked]]
>> Sent: Monday, November 14, 2005 7:52 PM
>> To: Bernie Volz (volz)
>> Cc: Ralph Droms (rdroms); DHCP discussion list; Ted Hardie;
>> [email-masked]
>> Subject: Re: [dhcwg] Re: I-D
>> ACTION:draft-ietf-geopriv-dhcp-civil-07.txt
>>
>>
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 18 Nov 2005 22:08:17 -0500

Let me try some text to  have something to beat up:

Generally, location information is transmitted from the DHCP server  
to the DHCP client. Under limited special circumstances, a DHCP  
client may want to inform the DHCP server of its current location,  
e.g., to facilitate system management of wireless end systems  
equipped with location measurement equipment such as GPS. Thus,  
clients MAY implement the transmission of location information to the  
server. Unlike the server-to-client transmission, this poses unique  
privacy concerns since the client has no way to express its detailed  
privacy preferences to the server. For example, clients may not want  
the server to use location information for anything but system  
management and emergency calling purposes. To limit the privacy  
exposure, all client-provided location information has an implied  
privacy policy that only allows usage by the receiving entity. It  
cannot be forwarded to other entities. Old location information must  
not be retained after the information has been updated by the client  
or the lease expires.

The DHCP client would use the [???] messages for this purpose.

Implementations MUST allow clients to be configured so that they do  
not send location information to the server and SHOULD/MUST operate  
on an opt-in basis, i.e., in a default configuration, no location  
information is transmitted to the server.

--- end text ---

DHCP experts should probably fix up my wording imprecision.

Henning

On Nov 18, 2005, at 9:51 PM, Bernie Volz ((volz)) wrote:

> Ted:
>
> Propose some text? I think your summary is correct, but I'm not sure
> exactly what your end proposal is. If it is essentially Henning's with
> more detail on why the server isn't allowed to distribute this
> information (if received from the client), I'd be happy.
>
> - Bernie
>
>
>> From: Ted Hardie [mailto:[email-masked]]
>> Sent: Friday, November 18, 2005 6:36 PM
>> To: Bernie Volz (volz); Henning Schulzrinne
>> Cc: Ralph Droms (rdroms); DHCP discussion list; [email-masked]
>> Subject: RE: [dhcwg] Re: I-D
>>>>> I assume this default "do not distribute" policy applies
>>>>>
>> for either
>>
>>>>> direction (client to server (server should not distribute)
>>>>>
>>>> and server to
>>>>
>>>>> client (client should not distribute)) or do you propose to
>>>>>
>>>> have this
>>>>
>>>> do what I want with it.") I'm ignoring the case here of
>>>>
>> the abductee
>>
>>>> case where the kidnap victim is told that if he reveals
>>>>
>> his location,
>>
>>>> make a choice ("keep this to yourself"); this is not
>>>>
>> currently in the
>>
>>>>> If this policy doesn't apply when from server to client
>>>>>
>>>> (what the I-D
>>>>
>>>>> currently allows), what policy does apply to the
>>>>>
>>>> information the client
>>>>
>>>>> receives as this privacy information isn't communicated?
>>>>>
>>>> And, thus isn't
>>>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 19 Nov 2005 18:06:57 -0500

> I'm fine with the above, but I think this potentially crosses the line
> with what Ted was saying: "((Server here does not mean box; it means any
> other function, even if it is within the same administrative domain or
> resident in the same box)". I think Ted's definition is a bit extreme
> and agree with your wording. I think there are valid uses of this
> information by other "components" in special/restricted circumstances
> (such as what you specify since DHCP has nothing to do with emergency
> calling itself). And, if a client really doesn't want the information to
> be used for anything, it just doesn't supply it!
> 
> Perhaps that's a better way to view this ... While the information
> should not be distributed by the receiving server, it may be used for
> functions within the server's administrative domain. A client that
> doesn't agree to those rules of use by the server is always free NOT to
> provide the information. Therefore, clients SHOULD NOT send this by
> default.

I agree that 'single server' is too narrow and pretty useless, plus it 
gets into trouble even with standard setups consisting of relay agents 
or a separate database backend server. 'Administrative domain' works for 
me, as it seems pretty well defined by common usage in lots of protocol 
documents.

>>The DHCP client would use the [???] messages for this purpose.

Addendum: I believe this should only be permissible in unicast 
DHCPINFORM, not in any broadcast requests, for obvious privacy reasons. 
(DHCPREQUEST seems to be commonly used in broadcast mode. If we allow 
DHCPREQUEST, it seems too likely that lazy implementors will include the 
information in broadcast requests.)

Text:

The DHCP MUST use the unicast DHCPINFORM request for this
purpose.  In general, the client MUST NOT broadcast or multicast
location information.

> Old location information should/must be discarded when updated by a
> client in a subsequent transaction, when the lease is released by the
> client, or the lease expires.

Works for me.

As I said, I'd like to close this issue and move on. Please speak up 
soon if you disagree with this resolution or have text suggestions.

Henning

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 21 Nov 2005 17:11:39 -0600

Hmm.. Sounds like OBO to me. ;)

I actually think that network management find this misbehaving phone has
other better options at hand than this. If the server doesn't support
LCI then I don't think that this option is going to help, and if the
server does support LCI then other options such using the lease query
mechanism proposed in
http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-09.txt to
get the LCI data or relay data from the server directly.

I still think that the potential long term mess is far worse than the
short-term gains.

Cheers
James

> Sent: Tuesday, 22 November 2005 10:03 AM
> To: Winterbottom, James
> Cc: Randall Gellens; [email-masked]; DHCP discussion list
> Subject: Re: [Geopriv] RE: [dhcwg] Re: I-D
ACTION:draft-ietf-geopriv-dhcp-
> civil-07.txt
> 
> 
> 
> Winterbottom, James wrote:
> >>This does mean that a client has to make a possibly unpleasant
choice
> >>between not sending the information, and thus possibly making it
> >>harder be located in an emergency or possibly having poorer service
> >>in some other area, and sending it with no redistribution/retention
> >>limits.
> >
> >
> > [AJW] I simply don't understand this statement. If the end-point has
its
> > location, how is providing that location to a DHCP server going to
> > assist with emergency call routing?
> 
> It's a bit of a stretch, but the logic would be something like:
> 
> - End point knows location, but client application doesn't know how to
> retrieve or use it (this would include all current IP telephony soft
> clients, for example);
> 
> - in an enterprise environment, the proxy server gets to ask the DHCP
> server for location information (and uses it for emergency call
routing).
> 
> I agree that this is not a deployment scenario we should make the
> preferred outcome.
> 
> The more likely case is that this is used for network management
("find
> the misbehaving PC or phone").
> 
> 
> >
> > My personal opinion is that allowing the transfer of location from
the
> > client to the server in this manner is a significant stretch of the
> > intentions laid out in RFC-3694 and quite far reaching application
and
> > security implications.
> > Cheers
> > James
------------------------------------------------------------------------
> ------------------------
> > This message is for the designated recipient only and may
> > contain privileged, proprietary, or otherwise private information.
> > If you have received it in error, please notify the sender
> > immediately and delete the original.  Any unauthorized use of
> > this email is prohibited.
> >
------------------------------------------------------------------------
> ------------------------
> > [mf2]

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]