--Martin
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of James M. Polk
> Sent: Wednesday, 28 July 2010 11:57 AM
> To: geopriv@ietf.org
> Subject: [Geopriv] DHCP Location URI Option -08 submitted
>
> 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)."
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
