Subject: [Geopriv] LCP & Arch....

From: Marc Linsner <[email-masked]>
Date: Wed, 16 Sep 2009 16:52:27 -0400

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-

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 16 Sep 2009 19:05:12 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Linsner
Sent: Thursday, 17 September 2009 6:52 AM
To: GEOPRIV
Subject: [Geopriv] LCP & Arch....

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]

---

From: Brian Rosen <[email-masked]>
Date: Wed, 16 Sep 2009 20:26:27 -0400

First I would like to thank Ted for expressing better what my concern on the
non-OBO use of identity was.

Then, I think you are missing the important point of Ted¹s message: we
granted a special exemption to the LCP use of HELD because we had return
routability testing that assured us that the proffered identifier (IP
Address) was indeed the identifier of the device requesting its own
location.

You may recall that I was initially very worried about using the IP address
as an identifier because of the danger of spoofing.  I was persuaded, as was
the work group, that the return routability was in fact a good protection
against spoofing.  Identity-extensions doesn¹t have that kind of test.  It
just has this warning that the LIS has to have a way to verify.  I don¹t
think that is feasible.  There are some exceptions: a MAC address on the
same L2 for example.

OBO has to work with the full LO with the ruleset.  I would be a lot more
comfortable with identity extensions if it did the same in all
circumstances.

Brian

On 9/16/09 8:05 PM, "Thomson, Martin" <[email-masked]> 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
> 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
>  
> 
> 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.).
> 
> when a target is discovering it¹s own location (trust relationships, identity
> verification, rule-based policy, etc.).
> 
> -Marc- 
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 16 Sep 2009 19:49:39 -0500

If we are talking about identity, then it's not the LCP policy.  I've agreed to that already, based on Marc's earlier comments [1].  I'm currently working up some proposed text for the identity draft that makes this distinction clear.

The crux is, the Rule Maker decides on what policy applies.  That policy can cover all the concerns you've laid out.

What were saying here is that the LCP case is no exception either, and that a Rule Maker decides whether the LCP policy (with the all special conditions that we've laid out to date) is appropriate or not.

--Martin

[1] <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/19>

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, 17 September 2009 10:26 AM
> To: Thomson, Martin; Marc Linsner; GEOPRIV
> Subject: Re: [Geopriv] LCP & Arch....
> 
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf Of
> > Marc Linsner
> > ---------------------------------------------------------------------
> ---------
> > ------------------
> > ---------------------------------------------------------------------
> ---------
> > ------------------
> > [mf2]
> >

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Sep 2009 21:32:56 -0700

At 7:05 PM -0500 9/16/09, Thomson, Martin 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
>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.

I think "LCP Policy" sounds like rules from a rulemaker.   Which raises the question:
why are the results of this application of the rules not bound into a PIDF-LO in
all cases? (Now that I have caught up a bit further, I see Brian asked the same
question).

I heard the "thin edge of the wedge" argument answered as "pragmatic applications
won out"; but GEOPRIV has always been about ensuring that the tools were there
for the privacy-concerned individuals to indicate their desires--and it has been in
the face of those "pragmatic" desires from providers all along.  If we include the
PIDF-LO rules along with location to the target, no harm is done that I can see.
Why not, then?

I also heard someone ask whether this was geopriv or ecrit.  It's
geopriv, and that means that the many special  exemptions granted to emergency
services are not the baseline here.  It's still an important use case, but we don't
start from that model, any more than we start from the model that it is up to
the target to prove that someone *doesn't* have the right to their location.

Lastly, I still didn't hear anyone answer my question about whether this
document has been shared with apps-discuss or SAAG.  I'll assume the answer
is no, then.  May I ask that the WG Chairs solicit that review now, in current
round of discussion?

thanks,

Ted Hardie

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 16 Sep 2009 23:42:09 -0500

> I think "LCP Policy" sounds like rules from a rulemaker.   

Yup.

Think of it as a GEOPRIV "profile" that we make available to rule makers who might struggle with the complexity of GEOPRIV. 

> Which raises
> the question:

Good question.  I can't answer that.  Is this something that you believe we need to address in our revision of the DHCP LCP with RFC3825bis?

> If we
> include the

Sounds reasonable.

> May I ask that the WG Chairs solicit that review now, in
> current
> round of discussion?

Certainly worth taking the document on the rounds of all the other relevant groups sooner than later.  Since we're in the process of trying to discover issues, now seems like a good time.

--Martin

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Sep 2009 10:57:08 +0300

I guess we are only discussing terminology here (and most people outside
the GEOPRIV working group very likely have no interest in any of these
discussions nor the outcome). 
 
So, some time ago we defined the term LCP in a quite loose way when we
worked on the L7 LCP topic. 
The goal was to have some "label" for referring to protocols
(DHCP,HELD,LLDP-MED,..) that provide the Device with its own location
information. 
 
Marc, what should we do to have a single term for these protocols that
is still meaningful and does not cause heartburn in the DHCP vs. HELD
camp? 
 
Ciao
Hannes
 
PS: I noticed that it might be useful to re-read the draft
http://www.ietf.org/id/draft-ietf-geopriv-l7-lcp-ps-10.txt regarding the
terms 'Device' vs. 'Target'... 

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext Marc Linsner
	Sent: 16 September, 2009 23:52
	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-

---

From: Richard Barnes <[email-masked]>
Date: Thu, 17 Sep 2009 07:14:23 -0400

> is no, then.  May I ask that the WG Chairs solicit that review now, in current

Duly noted.  I will solicit those reviews.

--Richard

---

From: Marc Linsner <[email-masked]>
Date: Thu, 17 Sep 2009 08:21:35 -0400

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-

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 17 Sep 2009 10:20:12 -0400

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:

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:

> 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.
> 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-
>
>
>> 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.
>>
>> Behalf Of Marc Linsner
>> 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-
>>
>>
>>

---

From: Marc Linsner <[email-masked]>
Date: Thu, 17 Sep 2009 11:59:24 -0400

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-

> I. In DHCP, the steps above are as follows:
This mechanism can only fulfill use case #1
> 2. Authorization: implicit because LR is the Target
Authorization: Rulemaker: well-known TDIL policy

> II. In the base HELD protocol, the steps are:
This mechanism can only fulfill use case #1
> or may forbid even that for certain Targets, per Martin's email [1]/
Authorization: Rulemaker policy (most cases = well-known TDIL policy)

> since it depends on the identifier presented (per Richard's email [2])
Authentication: Required, regardless how difficult
> or may forbid even that for certain Targets, per Martin's email [1]/
Authorization: Rulemaker policy
> 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
>> LCP is one mechanism that assists the function whereby a Œtargets
>> discovers it location¹ (TDIL)
>> comparison such to draw functional parallels.  Now I¹m wondering if
>> that¹s even necessary.
>> 
>> -Marc-
>> 
>> 
>>> I wouldn¹t go so far to label LCP as an aberration (more below),
>>> but I agree with the basic message.
>>> 
>>> 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
>>> authentication, privacy protections, rule makers, etcŠ), it¹s just
>>> And like Marc says, we should never assume that this policy exists;
>>> that wouldn¹t be right.
>>> 
>>> --Martin
>>> 
>>> 
>>> that LCP was a Œfunction¹ that GeoPriv would provide, but LCP is
>>> be considered Œnot an LCP¹ and follow the whole GeoPriv privacy/
>>> 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
>>> it¹s own location (trust relationships, identity verification, rule-
>>> based policy, etc.).
>>> 
>>> -Marc-
>>> 
>>> 
>>>

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 17 Sep 2009 12:13:10 -0400

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:

>>>> that wouldn’t be right.

---

From: Marc Linsner <[email-masked]>
Date: Thu, 17 Sep 2009 12:25:15 -0400

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" <[email-masked]> wrote:

>>>>> --------------------------------------------------------------------------
>>>>> --
>>>>> --------------------
>>>>> --------------------------------------------------------------------------
>>>>> --
>>>>> --------------------
>>>>> [mf2]

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 17 Sep 2009 19:32:05 -0500

This analysis is telling.  With Marc's clarifications, we essentially have the same process for all scenarios.  The only thing that differs is the policy.

That's OK, because we don't set policy.

So, I'm left wondering why there is an apparent disagreement.  Our task seems clear to me: identify areas where policy is necessary and highlight the associated problems.

--Martin

> Behalf Of Alissa Cooper
> Sent: Friday, 18 September 2009 12:20 AM
> To: GEOPRIV

---

From: Marc Linsner <[email-masked]>
Date: Fri, 18 Sep 2009 08:30:01 -0400

Martin,

On 9/17/09 8:32 PM, "Thomson, Martin" <[email-masked]> wrote:

> This analysis is telling.  With Marc's clarifications, we essentially have the
> same process for all scenarios.  The only thing that differs is the policy.
> 

Agree, 'we' don't set policy.  But, we must provide the tools that allow:

1) The LIS to chose the correct policy.
    a) Authenticate the requester
    b) Provide the policy decision engine with the identity of the requester
    c) Provide the policy decision engine with the posture of the request
(3rd party/target/etc).
    c) May require a common requester identity architecture??
        i) Is 192.168.1.73 a valid identity for 3rd party LR? (not to be
confused with the identity required for location determination)

All of the above is accomplished with the (2) LCPs we've created and SIP
Presence.  

What am I missing?

-Marc- 

> 
> So, I'm left wondering why there is an apparent disagreement.  Our task seems
> clear to me: identify areas where policy is necessary and highlight the
> associated problems.
> 
> --Martin
>

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 18 Sep 2009 13:39:17 -0400

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.

---

From: Marc Linsner <[email-masked]>
Date: Fri, 18 Sep 2009 16:23:05 -0400

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."

> 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-

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 20 Sep 2009 20:11:09 -0500

> What am I missing?

Nothing.  

We might have a different view of what is necessary for this group to produce though.

I think that you are obliquely suggesting that we need to establish a baseline for what identity can be used, how it is used, references to the mechanisms to employ, etc...  All that would be necessary for a Rule Maker to identify and authorize arbitrary Location Recipients.

That's really great if you think that third party requesting is part of the end-game architecture.  Third parties from all over request location information I don't think that.  In fact, we'd be wasting our time if we pursued that.  It's a big problem that isn't worth solving.  Not because it wouldn't be useful, but because it isn't necessary.

Location by reference solves much of this problem by allowing us to move from location configuration (local) to presence (global) where all those sorts of problems are in the process of being solved.  That's the end-game I'm thinking about.

Third party requests don't really figure in this end-game.  Third party requests exist because we have an immediate need that cannot be addressed by the end-game solution.  That need has very specific requirements that held-identity-extensions addresses.

Let me suggest an alternative then.  We state the following: the means by which authentication of requesters is established is a matter for local policy.  Tools that are provided include TLS (authentication by shared private key, PKI, etc...) and HTTP authentication.  If you like, you can authenticate based on the source IP of the request if that suits you.

It's all up to the discretion of the Rule Maker.

--Martin

---

From: Marc Linsner <[email-masked]>
Date: Mon, 21 Sep 2009 17:12:54 -0400

Martin,

In-line....

> We might have a different view of what is necessary for this group to produce

agree

> 
> I think that you are obliquely suggesting that we need to establish a baseline
> for what identity can be used, how it is used, references to the mechanisms to
> employ, etc...  All that would be necessary for a Rule Maker to identify and
> authorize arbitrary Location Recipients.

Agree, I believe that is our task at hand.

> 
> That's really great if you think that third party requesting is part of the
> end-game architecture.  Third parties from all over request location
> information I don't think that.  In fact, we'd be wasting our time if we
> pursued that.  It's a big problem that isn't worth solving.  Not because it
> wouldn't be useful, but because it isn't necessary.
> 
> Location by reference solves much of this problem by allowing us to move from
> location configuration (local) to presence (global) where all those sorts of
> problems are in the process of being solved.  That's the end-game I'm thinking
> about.
> 
> Third party requests don't really figure in this end-game.  Third party
> requests exist because we have an immediate need that cannot be addressed by
> the end-game solution.  That need has very specific requirements that
> held-identity-extensions addresses.

First, I consider 'third party' to include other contexts than what you are
inferring here.  My spouse asking my presence server for my location is a
'third party' request from a RuleMaker pov.

Hence, I have to assume that your use of 'third party' in this context is
probably closer to the previous term used, OBO.  So, I assume we are talking
about the need to discover a location on behalf of a location unaware
device, which seems to coincide with what others are asking to solve.

> 
> Let me suggest an alternative then.  We state the following: the means by
> which authentication of requesters is established is a matter for local
> policy.  Tools that are provided include TLS (authentication by shared private
> key, PKI, etc...) and HTTP authentication.  If you like, you can authenticate
> based on the source IP of the request if that suits you.
> 

Before we can agree to the above, we have to agree that HELD identity
extensions is strictly for the use-case described (further) above,
third-party/OBO (we need to pick one term), and can not be used by a target
discovering it's own location from a Rulemaker pov.  Hence, HELD identity
extensions is not an LCP.  Obviously a target could request a location
associated with an identity that happens to be it's own identity from a
different obscure layer, but since there is no way for the Rulemaker to
ascertain the request is from a target, the only possible policy that can be
applied in this use case, is a third-party/OBO policy.

Let's establish this before continuing.

-Marc-

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 22 Sep 2009 00:02:40 -0500

Marc,

We're not agreeing yet...

Yes, I would like to solve the problem that was previously known as OBO.  That is, third party requests that use the mechaisms provided by held-identity.  

I'll note that OBO is a term that isn't necessary because we already had adequate labels in the GEOPRIV model.

That's right.  I'm saying that we don't need to justify our use case in privacy terms.  Not any further than we have already.

> third-party/OBO (we need to pick one term), and can not be used by a
> target discovering it's own location from a Rulemaker pov.  

We did agree.  It's not LCP.  It's someone requesting the location of someone else.

--Martin

---

From: Marc Linsner <[email-masked]>
Date: Wed, 23 Sep 2009 16:30:32 -0400

Martin,

> 
> Yes, I would like to solve the problem that was previously known as OBO.  That
> is, third party requests that use the mechaisms provided by held-identity.
> 

OK, I can accept calling this is a limited use case third party model.

> 
> That's right.  I'm saying that we don't need to justify our use case in
> privacy terms.  Not any further than we have already.

You may get other comments around end-user knowledge of location
dissemination/rules, etc.

> We did agree.  It's not LCP.  It's someone requesting the location of someone

Then state this is not addressing a target discovering it's location
use-case in the draft.

I believe the draft takes too many liberties with "LCP Policy".  That policy
still falls under the Rulemaker and is not a given.

Just to be clear, the draft is asking for the functional equivalent of
pres:[email-masked], correct?  Knowing this allows me to
compare the security/privacy attributes.

-Marc-

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 23 Sep 2009 18:16:04 -0500

Marc,

> dissemination/rules, etc.
 
There is already text in the document regarding the need for the establishment of prior authorization by Rule Makers.  

Now, if your meta-policy dictates that an end-user is a Rule Maker, you get what you want.  But end-user knowledge is not mandated, even if it is arguably a desirable goal in many cases.

If the user is only one of many Rule Makers, then it might be the wish of a non-end-user Rule Maker that the end-user is not aware of the rules it creates.  Yes, that's not pretty, but I'd argue that a) GEOPRIV permits this, and b) that it's an ugly fact of life and not our problem.  If you have a problem with that, I'd suggest a career in public policy.

> pres:[email-masked], correct?  Knowing this allows
> me to compare the security/privacy attributes.

Not functionally equivalent in all aspects, but I think that they are equivalent from the perspective of applying GEOPRIV principles (i.e. RFC 3693 and geopriv-arch).  The security story might be different.  For instance, SIP generally has intermediaries, which adds complexity that doesn't apply here.

--Martin