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:
1. Authentication: based on DHC
2. Authorization: implicit because LR is the Target
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:
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)
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])
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)
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])
2. Authorization: based on Rule Maker rules
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
