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
