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

I don't get the hang up on business models. Nor the judgmental attitude.
Nevertheless, it's irrelevant.

The purpose is to support emergency calling for VoIP as soon as
possible. 6000 separately managed and funded PSAPs do not change over
night - they don't even change over a decade.

Presumably we'd all like to see the plug being pulled on the switch
circuit networks as soon as possible, get the global population onto the
richer platform of the Internet. Currently E911 is a barrier to VoIP
adoption - it's also the case that using VoIP currently means people
suffer a degradation in their ability to reliably receive emergency
support. Note that i2 also applies globally and there are participants
from global operators in ESIF. Getting i2 implemented asap is very
important and, by providing the impetus to put LIS infrastructure in
place in the access networks, it also lays the groundwork for the
eventual migration to i3/ECRIT. It's a good thing.

If you discard the conspiracy theories, you should be able to take i2 at
face value and see that the value of location by reference in this
context has nothing to do with business models. I'm certainly happy to
spend some time going over the architecture and explaining its origins
and imperatives if you like Hannes. Or getting James W to :)

Cheers,
Martin

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> Sent: Friday, 15 September 2006 12:20 AM
> To: Dawson, Martin
> Cc: Henning Schulzrinne; Brian Rosen; GEOPRIV
> Subject: Re: [Geopriv] coming to terms on location by reference
>
> If NENA is going along this path then I am seriously concerned about
the
> complexity they create just to support some broken business models.
>
> This has nothing todo with security benefits.
>
> Ciao
> Hannes
>
> Dawson, Martin schrieb:
> > So.. ah... satellite (TV receiver I assume you mean?) and DVD
encryption
> > keys suffered from the vulnerability that the keys are static and
the
> > resource that tested the key was replicated to mass market deployed
> > devices.
> >
> > The "new generation" of DRM that you allude to relies on network
access
> > for authorization, has temporal validity windows, and relies on
public
> > key encryption. That is, they are moving to the same sort of
> > architecture being adopted to control LIS access. VESA as prescribed
by
> > NENA provides the analog of the control the DRM servers developed
for
> > contemporary digital media distribution/protection. FIPS is
specified to
> > ensure that entities such as VESA and the VPC operators apply the
right
> > controls to cert management. It is a jurisdictional issue to ensure
that
> > standards such as FIPS are a requirement.
> >
> > You may not feel confident in this technology but it's what the
world
> > currently has. And it's vital to far more than controlling access to
> > location by emergency services. Rather than avoid developing systems
> > that make use of such technology, then, perhaps it would be better
to
> > focus on evolving and improving that particular technology. Whatever
is
> > used for authentication once you do provide these improvements will
be
> > equally applicable to location references - and, for that matter, to
> > digital signatures on location by value, so both ends of the
location
> > food chain can benefit from the effort.
> >
> > Cheers,
> > Martin
> >
> >> -----Original Message-----
> >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> >> Sent: Thursday, 14 September 2006 11:30 AM
> >> To: Brian Rosen
> >> Cc: GEOPRIV
> >> Subject: Re: [Geopriv] coming to terms on location by reference
> >>
> >>
> >> 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.
> >>
> >> 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.
> >>
> >>> 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 don't think authentication adds much value here. 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".
> >>
> >>
> >>
> >>>
> >>
> >> _______________________________________________
> >> 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
> >
> >
>

------------------------------------------------------------------------------------------------
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:04:22 -0500