My recent tack of attempting to change the use of "LCP Policy" is due to
it's overloaded use. LCP was 'allowed' by the GeoPriv community because it
provides a basic feature. It guarantees a posture to the Rulemaker policy
engine about a request for location - it's the target. DHCP guarantees the
request is from the target and will deliver the LCI to the target via the
layer 2 mechanisms it utilizes. Baseline HELD performs the same function
using 3-way handshaking and the return routability of IP. Neither of these
mechanisms usurps the Rulemaker Policy engine from doing it's thing.
It has long been the belief within the GeoPriv community that a target has
the unalienable right to it's own location information, but that is no more
than the opinion of this group of engineers. Upon implementation of the
tools GeoPriv delivers, the *real* 'Rulemaker' will decide.
Example: A target could request DHCP option 123/99 within a discover packet
and the Rulemaker policy can be to NOT deliver the LCI in the DHCP offer.
Or, the Rulemaker can return an LCI with only City, State information. The
same holds true with baseline HELD. Hence, the LCP functioned as designed,
the Rulemaker made the final decision.
The policy is actually associated with a target discovering it's own
location, not the protocol label that carried the location request. Hence
the term "LCP Policy" is a misnomer.
On to your question, my suggestion would be:
"A location configuration protocol (LCP) is one mechanism that can be used
by a target to discover it's own location from a LS/LIS. The LCP provides
functions in the way it captures, delivers, and transports location
requests/responses to/from the LS/LIS such that the LS/LIS can trust that
the location requests delivered via the LCP are in fact from/to the target."
> Assuming the blank gets filled in, I think we all have the same
> understanding of what an LCP policy is: it's an authorization policy
> that only allows Targets to obtain their own locations. Depending on
> how you fill in the blank, this might create the slightly confusing
> situation where a LIS implements HELD identity extensions (and thus
> cannot be considered to be using an LCP) but follows the LCP policy
> (because it is provisioned with a policy that only allows it to
> provide Targets with their own locations). This confusion may or may
> not be surmountable by clarifying the text in held-identity.
The heartburn I have from this paragraph is that HELD identity extensions
does not offer any of the characteristics of an LCP. A location request
received by a LS/LIS via HELD identity extensions must perform the
authentication and posturing of the request prior to making a policy
decision. These two functions (authentication and posturing) are
pre-delivered by an LCP in a trustable manner such that the LS/LIS doesn't
have to perform them. HELD identity extensions can not deliver that LCP
function, hence my request to scrub LCP from that document.
I hope this is understandable and helps,
-Marc-
On 9/18/09 1:39 PM, "Alissa Cooper" <acooper@cdt.org> wrote:
> Ok. So coming back around to how we characterize "LCP" and "LCP
> policy" in geopriv-arch:
>
> Let's discuss LCPs separately from LCP policy, because they are
> distinct.
>
> It sounds like what you are wanting is a description of LCP that goes
> something like: "A location configuration protocol is a protocol that
> provides Targets with their own locations and relies on ___________ to
> authenticate those Targets." How would you fill in the blank?
>
> Assuming the blank gets filled in, I think we all have the same
> understanding of what an LCP policy is: it's an authorization policy
> that only allows Targets to obtain their own locations. Depending on
> how you fill in the blank, this might create the slightly confusing
> situation where a LIS implements HELD identity extensions (and thus
> cannot be considered to be using an LCP) but follows the LCP policy
> (because it is provisioned with a policy that only allows it to
> provide Targets with their own locations). This confusion may or may
> not be surmountable by clarifying the text in held-identity.
>
> On Sep 17, 2009, at 12:25 PM, Marc Linsner wrote:
>
>> Nothing prevents changes to the authorization policy when utilizing
>> the DHCP
>> mechanism. The LIS function decides authorization, DHC simply
>> provides
>> authentication. Until now, everyone has assumed a TDIL policy is
>> utilized
>> with the DHCP mechanism, but there is nothing inherent in the
>> protocols that
>> would lockdown the policy. That would be an implementation choice.
>>
>> -Marc-
>>
>>
>> On 9/17/09 12:13 PM, "Alissa Cooper" <acooper@cdt.org> wrote:
>>
>>> Agreed on all these points, except the idea that there's a Rule Maker
>>> in DHCP location configuration. If the policy is not changeable, what
>>> is the use of claiming that there is a Rule Maker?
>>>
>>> On Sep 17, 2009, at 11:59 AM, Marc Linsner wrote:
>>>
>>>> Alissa,
>>>>
>>>> I don't believe you are comparing use cases, you are comparing
>>>> mechanisms.
>>>>
>>>> The use cases are more simple.
>>>>
>>>> 1) A target discovering it's location (TDIL)
>>>> 2) Third party discovering someone else's location
>>>>
>>>> more in-line.......
>>>>
>>>> -Marc-
>>>>
>>>>
>>>> On 9/17/09 10:20 AM, "Alissa Cooper" <acooper@cdt.org> wrote:
>>>>
>>>>> Before we get back to the terminology question that Marc has raised
>>>>> regarding LCP, it might be useful to map out the use cases we are
>>>>> discussing to see where the real differences are. I have made an
>>>>> attempt below based on the recent discussions -- are these the
>>>>> distinctions that we should be making?
>>>>>
>>>>>
>>>>> In the rough process for an LS providing location to an LR, the LS:
>>>>>
>>>>> 1. Authenticates the LR.
>>>>> 2. Checks whether the LR is authorized to receive the location it
>>>>> requested.
>>>>> 3. Provides the location if the LR is authorized.
>>>>>
>>>>> I think we have four basic use cases that we've been comparing.
>>>>>
>>>>> I. In DHCP, the steps above are as follows:
>>>> This mechanism can only fulfill use case #1
>>>>>
>>>>> 1. Authentication: based on DHC
>>>>> 2. Authorization: implicit because LR is the Target
>>>> Authorization: Rulemaker: well-known TDIL policy
>>>>
>>>>> 3. Provide LI (per 3825 or 4776) or location URI pointing to LO
>>>>> (per
>>>>> dhcp-lbyr-uri)
>>>>>
>>>>> II. In the base HELD protocol, the steps are:
>>>> This mechanism can only fulfill use case #1
>>>>>
>>>>> 1. Authentication: return-routeability of IP address
>>>>> 2. Authorization: based on Rule Maker rules (which may be
>>>>> equivalent
>>>>> to the "LCP policy" of only providing a Target with its own
>>>>> location,
>>>>> or may forbid even that for certain Targets, per Martin's email
>>>>> [1]/
>>>>> held section 9.3)
>>>> Authorization: Rulemaker policy (most cases = well-known TDIL
>>>> policy)
>>>>
>>>>> 3. Provide LO or location URI pointing to LO
>>>>>
>>>>> III. For a Target using a HELD identity extension to obtain its own
>>>>> location, the steps are:
>>>>>
>>>>> 1. Authentication: required, but we can't mandate anything detailed
>>>>> since it depends on the identifier presented (per Richard's email
>>>>> [2])
>>>> Authentication: Required, regardless how difficult
>>>>> 2. Authorization: based on Rule Maker rules (which may be
>>>>> equivalent
>>>>> to the "LCP policy" of only providing a Target with its own
>>>>> location,
>>>>> or may forbid even that for certain Targets, per Martin's email
>>>>> [1]/
>>>>> held section 9.3)
>>>> Authorization: Rulemaker policy
>>>>> 3. Provide LO or location URI pointing to LO
>>>>>
>>>>> IV. For an LR using a HELD identity extension to obtain some other
>>>>> Target's location, the steps are:
>>>>>
>>>>> 1. Authentication: required, but we can't mandate anything detailed
>>>>> since it depends on the identifier presented (per Richard's email
>>>>> [2])
>>>> Authentication: Required, regardless how difficult
>>>>> 2. Authorization: based on Rule Maker rules
>>>> Authorization: Rulemaker policy
>>>>> 3. Provide LO or location URI pointing to LO
>>>>>
>>>>> [1] http://www.ietf.org/mail-archive/web/geopriv/current/
>>>>> msg07874.html
>>>>> [2] http://www.ietf.org/mail-archive/web/geopriv/current/
>>>>> msg07880.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sep 17, 2009, at 8:21 AM, Marc Linsner wrote:
>>>>>
>>>>>> Martin,
>>>>>>
>>>>>> We still have a disconnect.
>>>>>>
>>>>>> LCP is one mechanism that assists the function whereby a Œtargets
>>>>>> discovers it location¹ (TDIL)
>>>>>> The LCP mechanism is specific to the action of the communication
>>>>>> protocol ensuring the requester of location is the target. That
>>>>>> is/
>>>>>> was the agreed to definition by the GeoPriv community.
>>>>>> Identity Extensions does not/can not employ the LCP mechanism.
>>>>>> The policy you want is the ŒTDIL policy¹.
>>>>>>
>>>>>> I suggest you divorce the term LCP from the Identity Extensions
>>>>>> draft. I earlier suggested that LCP be mentioned in the draft
>>>>>> as a
>>>>>> comparison such to draw functional parallels. Now I¹m wondering
>>>>>> if
>>>>>> that¹s even necessary.
>>>>>>
>>>>>> -Marc-
>>>>>>
>>>>>>
>>>>>> On 9/16/09 8:05 PM, "Thomson, Martin" <Martin.Thomson@andrew.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I wouldn¹t go so far to label LCP as an aberration (more below),
>>>>>>> but I agree with the basic message.
>>>>>>>
>>>>>>> I hope that HELD makes Marc¹s point absolutely clear:
>>>>>>>
>>>>>>> The LIS MUST
>>>>>>> verify that the client is the target of the returned location,
>>>>>>> i.e.,
>>>>>>> the LIS MUST NOT provide location to other entities than the
>>>>>>> target.
>>>>>>> Note that this is a necessary, but not sufficient criterion for
>>>>>>> authorization. A LIS MAY deny requests according to any local
>>>>>>> policy.
>>>>>>>
>>>>>>> There is no such Œright¹. Besides, we¹re not in any position to
>>>>>>> assign any Œrights¹.
>>>>>>>
>>>>>>> I think that the concept of ŒLCP policy¹ is a good way to address
>>>>>>> these concerns. This actually provides a way that we can treat
>>>>>>> an
>>>>>>> LCP as part of the architecture.
>>>>>>>
>>>>>>> This is the policy under which we imagine that a LCP server might
>>>>>>> operate. LCP has all of the functions that are required
>>>>>>> (requester
>>>>>>> authentication, privacy protections, rule makers, etcŠ), it¹s
>>>>>>> just
>>>>>>> that most of these are hard-coded. However, we need to be
>>>>>>> absolutely clear when we are making statements that depend on
>>>>>>> this
>>>>>>> policy.
>>>>>>>
>>>>>>> And like Marc says, we should never assume that this policy
>>>>>>> exists;
>>>>>>> that wouldn¹t be right.
>>>>>>>
>>>>>>> --Martin
>>>>>>>
>>>>>>>
>>>>>>> From: geopriv-bounces@ietf.org [mailto:geopriv-
>>>>>>> bounces@ietf.org] On
>>>>>>> Behalf Of Marc Linsner
>>>>>>> Sent: Thursday, 17 September 2009 6:52 AM
>>>>>>> To: GEOPRIV
>>>>>>> Subject: [Geopriv] LCP & Arch....
>>>>>>>
>>>>>>> To add more to my rant about LCP on the interim meeting call
>>>>>>> yesterday.....
>>>>>>>
>>>>>>> LCP is an aberration of the GeoPriv architecture. Early on, the
>>>>>>> GeoPriv work group agreed to allow LCP based on the fact the
>>>>>>> underlying communication protocol would ensure the LCI provided
>>>>>>> belonged to the recipient. Hence, no work required at the LS/LIS
>>>>>>> to verify that the requester is the target. It was never agreed
>>>>>>> that LCP was a Œfunction¹ that GeoPriv would provide, but LCP is
>>>>>>> simply an aberration that shares the baggage associated with the
>>>>>>> GeoPriv Privacy architecture with a communication protocol that
>>>>>>> can
>>>>>>> provide the guarantees as described.
>>>>>>>
>>>>>>> Hence, we have created 2 LCP solutions, DHCP and (baseline) HELD.
>>>>>>> Both these mechanisms protect the privacy of the location data as
>>>>>>> they guarantee that the target is the recipient. Any mechanism
>>>>>>> where the communication protocol cannot provide this guarantee
>>>>>>> MUST
>>>>>>> be considered Œnot an LCP¹ and follow the whole GeoPriv privacy/
>>>>>>> security architecture (policy set by rulemaker, enforced by LS/
>>>>>>> LIS,
>>>>>>> etc.).
>>>>>>>
>>>>>>> My hope is to dispel the myth that LCP is a Œright¹ that target
>>>>>>> has
>>>>>>> to gain access to it¹s own location data and GeoPriv must deliver
>>>>>>> on this Œright¹ at all costs. The overall privacy/security
>>>>>>> architecture must still be followed when a target is discovering
>>>>>>> it¹s own location (trust relationships, identity verification,
>>>>>>> rule-
>>>>>>> based policy, etc.).
>>>>>>>
>>>>>>> -Marc-
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>> --
>>>>>>> --
>>>>>>> --------------------
>>>>>>> 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]
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> _______________________________________________
> 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
