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
