RE: [Geopriv] WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

From: Brian Rosen ^lt;>
Date: Wed Feb 14 2007 - 23:20:54 EST

We think the cert problem is tractable.

The local PSAP, for example, can deal with its local access network
providers. The PSAP can sign the certs of the local providers. There are
not very many of them, and they are all local (at least in the sense that
there are local people, and local equipment).

Then the PSAP can check the certs.

We actually think we can have a real PKI for PSAPs, but just doing local
certification is feasible.

Enterprise is a little more difficult, just because of the numbers. I think
we can handle that too, because we have a set of issues to deal with that
involves enterprises, and we can get the cert in the mix.


> -----Original Message-----
> From: Dawson, Martin []
> Sent: Wednesday, February 14, 2007 4:44 PM
> To: Henning Schulzrinne
> Cc:
> Subject: RE: [Geopriv] WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-
> LOdigitalsignatures)
> Yes, I think the broader Internet issue of cert security etc. needs to
> be solved in the broader context. Location needs to ride on whatever the
> best state of the art is.
> I actually just think of the identity as a unique random number that the
> LIS generates. That, coupled, with the LIS identity makes for a globally
> unique identity that the location recipient can be comfortable with
> using to applying policy against without any user or network specific
> information having had to be conveyed.
> Cheers,
> Martin
> -----Original Message-----
> From: Henning Schulzrinne []
> Sent: Thursday, 15 February 2007 8:37 AM
> To: Dawson, Martin
> Cc:;
> Subject: Re: [Geopriv] WGLC
> ondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)
> I think we're in general agreement. I'm not sure what you mean
> precisely by "access network identify", but this doesn't have to be a
> NAS identity, say. It could just as well be a (public) IP address or
> any other token, so that it works for non-authenticated users, as
> long as these cannot spoof a large number of network addresses or
> similar. In some cases, a combination of a physical network port and
> identity may well be appropriate. If the PSAP gets 100 calls from
> "socket 17 at" or "AP 42 at the Anytown Starbucks", even
> if they all have different MAC addresses, something is likely fishy.
> The remaining hard problem of not having trustworthy certifiers
> remains and could make any such mechanisms moot. (Although today's
> email-return-routability CA mechanism makes it expensive to get
> dozens of certs, although fishers seem to pay for those with stolen
> credit card numbers...)
> On Feb 14, 2007, at 4:27 PM, Dawson, Martin wrote:
> > This is true, I agree.
> >
> > I think what we want to do is to make it as difficult as possible
> > to do that more than once for a given client identity in the
> > network. This, as nearly as possible, would make it the equivalent
> > of Trudy setting her phone to forward to 911. Eve could only make
> > one call at a time through it. Trudy could have two phones and etc.
> > but, really, Eve is constrained to requiring her partner to have
> > the equivalent amount of "presence" in the network as she is
> > attempting to use.
> >
> >> From a PSAP perspective, it is a concern that each call is a,
> >> presumably, bogus one but they are not particularly concerned as
> >> to whether it is Eve that is effectively dialling them rather than
> >> Trudy.
> >
> > So - the important thing is for the PIDF-LO to be associated with a
> > single apparent identity in the access network so that appropriate
> > policy can be applied against getting two calls arriving with this
> > identity. Note that this "identity" is the anonymous appearance of
> > a particular IP host in the network and nothing to do with
> > conveying an individual's real world identity or voice service
> > subscriber identity. The latter is not the access network's job.
> > Requirement 3 is about providing a mechanism for the access network
> > to convey this "access network identity" as part of the location
> > information.
> >
> > Cheers,
> > Martin
> --------------------------------------------------------------------------
> ----------------------
> 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 mailing list
Received on Wed, 14 Feb 2007 23:20:54 -0500

This archive was generated by hypermail 2.1.8 : Wed Feb 14 2007 - 23:20:18 EST