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