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
