RE: [Geopriv] coming to terms on location by reference

Well I certainly think that the location reference should require
authentication and authorization to use. I also think the lifetime of
the location reference should be dictated by the device when it requests
the reference and the LIS should delete the context when that lifetime
expires. I don't think it implies any more complexity than what must
already be pinned down for presence servers generally.

I'm gobsmacked by the degree of concern about nefarious business
interests. If the protocols only allowed for location by reference I'd
agree there'd be a bias. But not if it supports both models. It's naive
to think you can force an operator to make something free by biasing a
protocol specification. You might achieve a delay in the deployment of
the functionality you're trying to advocate. They can put a charging
function on a LIS and rack up your bill every time you make a location
request if they want. In the end they'll stay in business by making
sufficient revenue and margin on their invested capital. In the end the
cost of operating charging infrastructure around location capabilities
is likely to be not worth it when location capability becomes a
commodity amongst access networks. Then it'll be lumped in with
subscription revenue and they'll go back to overall price competition to
keep subscribers. Our goal should be to get location capability to
commodity status as quickly as possible - and that's not done by trying
to bias a protocol specification in some way you think access operators
will find unattractive. The same goes for net neutrality generally -
really - it only takes one operator to break ranks for the subscriber
churn to start hurting the others. I'm not going to stay with an access
provider that will only let me use their VoIP service, and worse, only
let me use it when I'm on the Internet in their access.

Cheers,
Martin

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> Sent: Friday, 15 September 2006 12:20 AM
> To: Henning Schulzrinne
> Cc: GEOPRIV
> Subject: Re: [Geopriv] coming to terms on location by reference
>
> Hi Henning,
>
> Henning Schulzrinne schrieb:
> >
> > On Sep 13, 2006, at 9:05 PM, Brian Rosen wrote:
> >
> >>
> >>> None of this addresses the more fundamental problem that I believe
> >>> that giving PSAPs "tickets" that allow unrestricted access to
> >>> location information is an extremely dangerous thing to do. Given
> >>> that this is GEO*PRIV*, we might want to consider this. This is
far
> >>> more important than adding "please, be nice and observe, if you
feel
> >>> like it" rules to PIDF-LO objects.
> >> I believe I agree with you, but I want to check my premises.
> >>
> >> I think if you give your location by value to anyone, including a
> >> PSAP, they
> >> can, if they want to, ignore your ruleset and send it to anyone.
> >
> > Indeed. But they only get my location during an emergency call,
which
> > presumably is a rare event.
> >
> >
> >>
> >> I believe we should treat the reference the same way: assume that
if
> you
> >> have it, the target authorizes you to get location, with the
ruleset.
> >
> > Right.
> >
> >
> >>
> >> This is security of object = security of reference
> >>
> >
> > Indeed, but this is only true if the reference doesn't give
unrestricted
> > access to the object.
> >
> > To be concrete: suppose I build that system that allows anybody that
has
> > my AOR and a VESA cert to get my location at any time. This is far
> > *less* secure than conveying in-band location, which limits my risk
to
> > one exposure, and only if I'm unlucky enough that the PSAP I'm
talking
> > to is misbehaving. In other words, rather unlikely.
>
> I agree.
>
> >
> > There are solutions, such as time-limited tokens, that don't have
this
> > catastrophic failure mode.
> >
> >
> >> I don't think you mean to have the reference have any more, but
> >> certainly no
> >> less security than the object itself.
> >
> > This strongly depends on the characteristic of the reference. If the
> > reference is not time-limited, it is far *less* secure, for the
reasons
> > I mentioned.
>
> I always assumed in the location-by-reference discussion we assume the
> properties outlined in the Geopriv-L7 design team draft.
>
> >
> >>
> >> So, it's kind of a ticket, but we aren't proposing to use
> >> authentication of
> >> the watcher as some additional security to the location
information:
> >> possession of the reference is the same as possession of the
location.
> >>
> >> That means we use our security mechanisms to restrict who gets the
> >> reference, exactly as we would use them if it was the object.
> >>
> >> Is that your position? It is mine.
> >
> > I think the statement security(reference) = security(value) is too
> > simplistic. I think a more accurate, but less pithy statement is
> >
> > exposure(reference) = exposure(all values for lifetime of reference)
> >
> > and even that's probably not quite right if the reference relies on
> > querier authentication exclusively. Thus, we need to be far more
> > specific about the reference. There are at least three kinds:
> >
> > (1) something guessable (your AOR, your phone number) or something
> > densely packed (an identifier where just about every identifier
value is
> > meaningful, so that I can just walk the identifier space until I
find
> > something interesting).
> >
> > (2) something crypto-random, but permanent (anybody who can
intercept
> > the reference can get your location forever)
> >
> > (3) something random and very temporary
> >
> > Only a reference with property (3) has defendable security
properties
> > that are roughly equivalent to a by-value transmission.
>
> I agree and that's what I referred to when I spoke about
> security(reference) = security(value)
> Additionally, I also assumed that the Location Recipient is allowed to
> retrieve the location object only based on the possession of the
> reference. No authorization by the LIS.
>
> >
> > I don't think authentication adds much value here.
>
> It does not add value from a security point of view. It is very useful
> if you want to setup a complex infrastructure to tie Location
Recipients
> (e.g., PSAPs, pizza shops, etc.) to access network providers. A flavor
> of net neutrality.
>
> Any system that gives
> > thousands of users access to any information, without need-to-know,
> > can't be secure since a single "mistake" exposes the private data of
all
> > users. We know that mistakes happen in cert issuance, even for
> > high-profile names like Microsoft. Alternatively, breaking into a
single
> > PSAP system, physically or electronically, will retrieve the
necessary
> > signing material to get full access to any user's location data.
This is
> > no different than handing out the same "secret" key to thousands of
> > users and hoping that it stays secret. We might as well have a
global
> > "root" password for all routers or Linux servers...
> >
> > This isn't a protocol flaw as such, but a fundamental security
design
> > flaw. In my view, a distinction without a difference.
> >
> > There are several examples of such catastrophic system failures. Two
I
> > know about are satellite access keys and DVDs, where indeed the bad
> > design of a single DVD player compromised the whole DVD DRM security
> > architecture. Needless to say, the successor architectures changed
the
> > "protocol".
> >
> >
> >
> Ciao
> Hannes
>
>
> >>
> >>
> >
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >
> >
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.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://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 14 Sep 2006 11:13:31 -0500