-Marc-
On 10/10/09 3:55 PM, "Alissa Cooper" <acooper@cdt.org> wrote:
> To try to close the loop on this:
>
> The text we had in -arch before was:
>> The process of providing a Target with its own location is known
>> within Geopriv as Location Configuration, and the LG that provides
>> such location is often described as a Location Information Server
>> (LIS). Protocols used exclusively to communicate location from a LIS
>> to a Target are known as Location Configuration Protocols.
>
> Based on your suggestion below and the terminology used throughout the
> rest of the document, here's what I'm thinking:
> The process of providing a Target with its own location is known
> within Geopriv as Location Configuration, and the LG that provides
> such location is often described as a Location Information Server
> (LIS). A location configuration protocol (LCP) is one mechanism that
> can be used by a Target to discover its own location from a LIS. The
> LCP provides functions in the way it obtains, transports and delivers
> location requests and responses between the LIS and the Target such
> that the LIS can trust that the location requests and responses
> handled via the LCP are in fact from/to the Target.
>
> Alissa
>
> On Sep 18, 2009, at 9:23 PM, Marc Linsner wrote:
>
>> Alissa,
>>
>> 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
