Looks good.
Pedantic question: Isn't this LS, not LG?
From my understanding of the model, the LG never provides location to another. In some cases, the LIS necessarily only acts as LS and the actual LG can be elsewhere.
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Marc Linsner
> Sent: Monday, 12 October 2009 11:25 PM
> To: Alissa Cooper
> Cc: GEOPRIV
> Subject: Re: [Geopriv] LCP & Arch....
>
> I obviously agree.... :^)
>
> -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
------------------------------------------------------------------------------------------------
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
