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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 18 Nov 2005 21:51:37 -0500

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

> -----Original Message-----
> 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 
> ACTION:draft-ietf-geopriv-dhcp-civil-07.txt
> 
> 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
> >>
> >>
> >>
> >> 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).
> >>
> 

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

---

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