Subject: [Geopriv] DHCP Location URI Option -08 submitted

From: "James M. Polk" <[email-masked]>
Date: Wed, 28 Jul 2010 04:57:03 -0500

Geopriv

Working with Richard help with the text, I submitted a new version of
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option-08.txt
with the following changes

to the last paragraph of the intro, I have replaced the sentence:

"All of this is outside the scope of this document (since this will 
not be accomplished using DHCP). "

with

"This document does not provide mechanisms for the LS to tell the 
client about policies or for the client to specify a policy for the 
LS. While an LS should apply an appropriate access-control policy, 
clients must assume that the LS will provide location in response to 
any request (following the possession model [RFC5808]).  For further 
discussion of privacy, see the Security Considerations. "

In the security section, I replaced the following text

"...not secure in a practical sense ..."

with

"does not provide security at the network layer.  Instead, it relies 
on lower-layer security mechanisms.  "

and replaced

"That said, having the location URI does not mean an unauthorized
    entity has the location of a client.  The location URI still needs
    to be dereferenced to learn the location of the client.  This
    dereferencing function, which is not done using DHCP, is done by
    requesting the location record at a Location Server, which can
    challenge each request it receives based on the policy provided by
    the Ruleholder.  The Ruleholder, as defined in RFC 3693, configures
    the authentication and authorization policies for the location
    revelation of a Target.  This includes giving out more or less
    precise location information in a response, therefore it can answer
    a bad-hat, but not allow it from learning exactly where a client is."

with

    "Once a client has a URI, it needs information on how the 
location server will control access to dereference requests.  A 
client might treat a tightly access-controlled URI differently from 
one that can be dereferenced by anyone on the Internet (i.e., one 
following the "possession model").  With the LuriTypes defined in 
this document, the DHCP option for delivering location URIs can only 
tell the user how long the URI will be valid.  Since the client 
doesn't know what policy will be applied during this validity 
interval, clients MUST handle location URIs as if they could be 
dereferenced by anybody until they expire.  For example, such open 
location URIs should only be transmitted in encrypted 
channels.  Nonetheless, location servers SHOULD apply appropriate 
access control policies, for example by limiting the number of 
queries that any given client can make, or limiting access to users 
within an enterprise.

Extensions to this option, such as [ID-POLICY-URI] can provide 
mechanisms for accessing and provisioning policy.  Giving users 
access to policy information will allow them to make more informed 
decisions about how to use their location URIs.  Allowing users to 
provide policy information to the LS will enable them to tailor 
access control policies to their needs (within the bounds of policy 
that the LS will accept)."

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 28 Jul 2010 18:29:34 +0800

That's great.  This addresses the authorization policy aspects very well.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James M. Polk
> Sent: Wednesday, 28 July 2010 11:57 AM
> To: [email-masked]
> Subject: [Geopriv] DHCP Location URI Option -08 submitted
> 
> Geopriv
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv