RE: [Geopriv] NENA Requirements

I have pointed out the flaw in the transitive trust model, where the access
network carrier vouches for the location of one of its customers. The
problem is liability. The access carrier gets to take on the liability of
the information being wrong, and gets no value in return. It seems so
unlikely to me that we could compel them to do it in a way that makes their
liability go away.

Imagine the following: an enterprise has a main campus and a satellite
campus. It has a T3 or Metro Ethernet service into its main campus, and it
has a dark fiber between the main campus and the satellite. Are you going
to demand that the T3 carrier serving 123 Main St sign a location for 456
Locust? AT BEST, all the access carrier could do is sign something that
says "I have a customer I know as Ajax Manufacturing, and I serve him at 123
Main Street". You can't assert that he is actually Ajax, and you sure won't
sign something that says 456 Locust.

Brian

> -----Original Message-----
> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> Sent: Wednesday, March 14, 2007 2:20 AM
> To: Ted Hardie; Andrew Newton
> Cc: Brian Rosen; GEOPRIV; Marc Linsner
> Subject: RE: [Geopriv] NENA Requirements
>
> Most certainly Ted - thanks for the mutual respect.
>
> On the enterprise issue and the possibility of using transitive trust -
> Yes, I posted a description the other day of how the assertion mechanism
> could be used in conjunction with the existing trust relationship
> between an Internet carrier and enterprises to minimize the population
> of certificate owners. That was the one that does come under the Nortel
> IPR that was raised.
>
> I know I do a lot of posts - the subject was "RE:
> [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)
> " and it was posted on the 9th of March (though my posts were held up
> for about 24 hours for some reason around that day). Rather than paste
> it all into this thread, I can send you a copy if you like.
>
> This situation has a precedent that predates Internet telephony as well.
> Large (physically/geographically) enterprises have always had an issue
> with the location associated with their outgoing trunk being a coarse
> one relative to their actual geographic footprint. In many jurisdictions
> - most states of the US even I think - this is just accepted. In some
> jurisdictions sufficiently large "establishments" are required to
> provide more precise location information - to a given area or number of
> floors. This has been a challenge in those jurisdictions and the
> solutions used involves a thing called PS-ALI, which is where the
> enterprise actually purchases an external database system and can
> configure the location associated with things called ELANs which end up
> being associated with the outgoing CLI as it is set by the PABX. This is
> clearly quite complex and costly - and I would suggest it is more so
> than using assertion via a transitive trust relationship on an existing
> LIS interface.
>
> I think jurisdictions could choose between the following with respect to
> enterprises:
>
> * Just use the carrier level location, signed by the provider. As above,
> this is if the additional precision doesn't represent a statutory
> requirement.
>
> * Provide a CA program that does cover large enterprises. There's a
> strict requirement on enterprises keeping their key information secure.
> It becomes part of their identity so it should be subject to much the
> same level of regulatory oversight as Sarbanes-Oxley applies to
> financial information. That's just IMHO of course.
>
> * Use a transitive trust mechanism via something like assertion as
> described above. It's very much the analog of PS-ALI (which may even be
> argued to be prior art - just a thought) but it's a lot more light
> weight from an implementation perspective.
>
> * Something else - and I'm genuinely open to suggestions.
>
> Between all these options, I think there is something workable for any
> given global jurisdiction. I'd prefer an option that supported the
> signing of the precise information that an enterprise can determine for
> itself. Credentialed location has value beyond emergency services
> whatever the jurisdiction requires for that particular application.
>
> I didn't understand the comment about "...location being so coarse as to
> eliminate the perceived value of signing..." Can you elaborate on what
> you mean? I didn't understand how a coarse location used for routing
> eliminated the tracability. The signature still identifies the source of
> the location whatever the precision of the information is.
>
> You had made the statement
>
> "... there may be other forms of protection that would achieve the same
> goals without the need for entering into the CA business."
>
> There may be - but I haven't seen a proposal. Hannes suggested that
> location by reference might do this, but I countered that a location
> obtained that way won't have the same characteristics as a signed
> location after all.
>
> The characteristics desired - that provide the hearty chunks for
> discussion are, as I've posted previously, that the location
> information:
>
> * Can be attributed to a recognized source
> * Has not been tampered with since generated at that source
> * Is applicable to a specific target identity
> * Is applicable at a particular point in time
>
> Can you propose something alternative to KPI to provide this?
>
> Cheers,
> Martin
>
> -----Original Message-----
> From: Ted Hardie [mailto:hardie@qualcomm.com]
> Sent: Wednesday, 14 March 2007 3:03 PM
> To: Dawson, Martin; Andrew Newton
> Cc: Brian Rosen; GEOPRIV; Marc Linsner
> Subject: RE: [Geopriv] NENA Requirements
>
> At 5:55 PM -0500 3/13/07, Dawson, Martin wrote:
> >In the case of the former, I accept NENA's word for it that they
> understand the problem space and can make a successful judgement with
> respect to succeeding. The membership consists of everyone from the
> carrier space through to the PSAPs. The constant repetition of the
> second point only emphasises that people don't understand how the
> credentials can be used.
>
> At least some of the examples that have been cited as challenges come
> from the
> enterprise space. Enterprises can and do select to use VoIP, and they
> can provide
> location to end-users (one original point of the DHCP option work was to
> allow
> wiremap database information to be transmitted easily to enterprise
> customers).
> There are many more enterprises than carriers (and there are, at least
> if I understand
> what you mean by carrier, many more network access providers in
> general).
> You have restated some complex discussion of the trade-offs as:
>
> "Certificate management is too complicated - people won't succeed"
>
> If you aren't planning to extend certificates to everyone who would need
> one in
> your model, you either won't succeed or you will cause a regulator to
> eliminate
> a market to achieve your goal. Neither would be, in my estimation, a
> good course of
> action. If you are going to extend certificates only to transit
> upstreams, then you
> have to include in your model how the transitive trust works from that
> transit
> upstream to the entity which provides location (e.g. the enterprise from
> its
> wiremap) and/or to the customer. Henning has suggested one possibility;
> I haven't
> considered it carefully yet, but the suggestion points in the right
> direction: re-use
> existing relationships to get where you need to go, don't try to create
> new ones.
> I am afraid that this challenges Richard's view, which states that trust
> relationships
> must persist through this transition, without recognizing that the
> parties to the
> relationships are increasing exponentially as we move to an
> Internet-based
> infrastructure. It says instead: build the infrastructure out of the
> trust relationships
> that are present in the Internet model, rather than trying to cut the
> old ones
> into the new cloth.
>
> You've also taken statements about the security trade-offs and filtered
> them down to:
> "PSAPs answer all the calls anyway so there's no point". Among the
> things you
> have removed from the soup of discussion were some pretty hearty chunks:
> that there may be other forms of protection that would achieve the same
> goals
> without the need for entering into the CA business; the idea that where
> the location
> signing proposal is adopted, it would be to inform the calltaker or
> manage the
> queue, rather than drop the call; and the clear statements that the
> kinds of location
> which are sufficient for call routing may be the only ones available in
> many
> circumstances and that these may be so coarse as to eliminate the
> perceived value
> of the signature even in the case where the signature guarantees that
> the call
> should go to that psap as it does not provide the traceability aspect
> that Henning
> notes also came with the previous system. I'm not sure that what's left
> is
> going to nourish discussion very well.
>
> We've all been at this for a long time, and some frustration at the pace
> of progress
> is natural. But if we stop listening to each other entirely, we're not
> going to get
> faster. I will commit to listening as carefully as I can to the issues
> you raise; I
> hope you do the same.
>
> Ted
>
>
> >
> >The requirements have been spelt out - and location signing has been
> proffered as the solution. The nay-sayers position is that the
> requirement should be discounted - they should offer a superior solution
> if they have one.
> >
> >I have never said that the IETF has no experts in the identified fields
> - have I?
> >
> >Cheers,
> >Martin
> >
> >
> >From: Andrew Newton [mailto:andy@hxr.us]
> >Sent: Wednesday, 14 March 2007 2:32 AM
> >To: Dawson, Martin
> >Cc: Brian Rosen; Ted Hardie; GEOPRIV; Marc Linsner
> >Subject: Re: [Geopriv] NENA Requirements
> >
> >
> >On Mar 13, 2007, at 11:11 AM, Dawson, Martin wrote:
> >
> >
> >NENA are "the experts here" when it comes to requirements. People in
> >this working group are trying to say what emergency services policy
> >should be and I believe that belongs with NENA for the US and
> equivalent
> >entities for other jurisdictions.
> >
> >Martin,
> >
> >I'm not sure what it is you are attempting to do, but to suggest that
> the IETF has no experts in the field of network security or Internet
> topology and cannot therefore apply that knowledge is quite simply
> wrong.
> >
> >Location signing has been offered as a requirement. It has been
> pointed out that location signing is a solution and not a requirement.
> It has also been pointed out that the notion of network topology that is
> being applied to VoIP by this solution does not match the way the
> Internet works.
> >
> >Also, it has been fair to question the actual use of location signing
> with respect to invalidly signed or unsigned location information. To
> date, nobody has offered an authoritative policy... it is all
> supposition. It seems rather silly to claim to be the authoritative
> voice on this issue when you cannot give concrete policy examples.
> >
> >-andy
> >
> >
> >
> >-----------------------------------------------------------------------
> -------------------------
> >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]
>
>
> --------------------------------------------------------------------------
> ----------------------
> 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, 15 Mar 2007 14:16:39 -0400