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

From: Andrew Newton <[email-masked]>
Date: Wed, 7 Mar 2007 10:20:25 -0500

On Feb 27, 2007, at 10:10 PM, [email-masked] wrote:
> - If the location provided verbally matches with the automated un- 
> signed/fail-signed location, be suspicious before dispatching. Post- 
> call investigation is required.
>
> - If the location provided verbally don’t match with the automated  
> signed location, process the call and report the error afterward to  
> the location source (presumably the LIS operator).

Guy,

Here's the problem with that logic.  Administrative screw-ups can  
cause both of those problems, yet one type of screw up is considered  
suspicious while the other type is not.  From a security perspective,  
this opens up a social engineering attack... the caller needs no  
technical skill to defeat the signed location.  All they need to do  
is just verbally disagree with it.

-andy
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Richard Barnes <[email-masked]>
Date: Wed, 07 Mar 2007 10:40:43 -0500

Andy,

Nonetheless, I think the general point stands that a signature on a 
location object gives the call center additional information that they 
can use as they please -- according to their own policy.

The utility of this information will vary according to a lot of factors: 
In a normal situation, it might be fine to ignore the signature (or even 
the whole LO) and just go with the verbal location.  In a high-PSAP-load 
situation (such a DoS), signature information could be useful to 
distinguish calls before any verbal contact is made.

In any case, there will need to be carefully-thought-out policies about 
how to use this information, but I think that it's worthwhile to make 
the information available in the first place.

--Richard

Andrew Newton wrote:
>> - If the location provided verbally matches with the automated 
>> un-signed/fail-signed location, be suspicious before dispatching. 
>> Post-call investigation is required.
>>
> Here's the problem with that logic.  Administrative screw-ups can cause 
> both of those problems, yet one type of screw up is considered 
> technical skill to defeat the signed location.  All they need to do is 
> just verbally disagree with it.
> 
> -andy

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 7 Mar 2007 10:50:13 -0500

Andy

In all of this discussion, you seem unconvinced that the 9-1-1 call taker
can deal with information that is marked suspicious, but may be correct.
This happens already, they do handle it okay, and they are comfortable with
information that may or not be correct.  A typical example is that the ALI
screen says one thing, the caller insists on another.  This is suspicious,
but permitted.  The response will always go to where the caller said to go.
There will be some follow up to determine how the discrepancy happened if it
turns out the caller was right.

Again, they do this now.  It works.  They want it.  

We're chasing our tail on this, and we need to figure a way out.  I get that
there are people who don't believe we get a sufficiently good defense to an
acknowledged threat out of signing location.  There are a group of us who
think we do.  Those of us who think so readily agree that unsigned location
can be valid.  However, we think the mechanism will effectively deter a very
large class of not-highly-skilled and not-well-financed attackers.

The largest problem continues to be that we are very significantly weakening
the security of location as we move to the geopriv way of doing things.
What used to be locked inside a wireline/wireless carrier's domain, with no
access by end users is turning into an end user controlled environment.
We're opening a huge security hole.  We need some effective strategies to
minimize this hole.  We can't close it as securely as it was.  We think
signatures are one way to significantly help.  You don't agree, I get it,
but it sure would help if you had a better way.  You are saying "no, no no"
and not "not that way, use this way".

Brian

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2007 10:20 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-
> LOdigitalsignatures)
> 
> 
> > - If the location provided verbally don't match with the automated

---

From: Andrew Newton <[email-masked]>
Date: Wed, 7 Mar 2007 11:23:32 -0500

Brian,

The problem is that the cure may end up worse than the disease.  The  
benefit is unknown or negligible, and the down sides can be downright  
harmful.  Place that against the added technical complexity and the  
fact that the solution is patent encumbered with an unknown right to  
use, and it is easy to see that the costs exceed the benefits.

As for another way, NENA has already provided that answer: only  
accredited VSPs can talk to PSAPs.  That puts the problem on par with  
the current solution of the PSTN.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 7 Mar 2007 11:36:03 -0500

Unless you can show that this is significantly different from the current
situation where you DO get suspicious data, and we DO handle it
satisfactorily, then I believe that we know the cure won't be worse than the
disease.  The benefit is known, and we have experience that the downside is
not harmful.  

Your suggestion that only "accredited" VSPs can send calls to PSAPs is
unworkable, although, again, there can be some suspicion associated with
calls originating from an entity not known to the PSAP.  However, that has
nothing to do with the problem at hand, since the VSP doesn't supply
location, the access network does.

Brian

> Sent: Wednesday, March 07, 2007 11:24 AM
> To: Brian Rosen
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]

---

From: Andrew Newton <[email-masked]>
Date: Wed, 7 Mar 2007 12:11:46 -0500

> disease.  The benefit is known, and we have experience that the  

Considering that nobody is able to offer concrete answers about what  
it is PSAPs will actually do with invalidly signed location data,  
there is no way you can know the harm.  A simple expired certificate  
can cause ALL calls to look suspicious, and that simple error can  
happen in the access network or in the PSAP.  The other thing you do  
not know because there is no current PSAP experience with it is the  
DoS vector of simply slamming the PSAP with invalid signatures that  
do nothing more than chew up CPU time.  You also do not know how much  
this technology will cost in licensing fees, or if it is even  
available under license.

> calls originating from an entity not known to the PSAP.

It isn't my suggestion, it is NENA's.  And they seem to be moving  
forward with it.

>   However, that has

No, the VSP conveys the information, either by value or reference.   
So it is relevant from a trust standpoint.  And FYI, for many, many  
cases, the location information will originate from the VSP.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 7 Mar 2007 12:40:57 -0500

Brian,

What if.......

The provided-by element of pidf-lo were a psuedo-random reference that
derived the same location value as the one presented.

<PROVIDED-BY>pres:[email-masked]</PROVIDED-BY>

It would be very easy to 'authenticate' the presented location value (by
dereferencing) and traceable to the author.

-Marc-

> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Wednesday, March 07, 2007 11:36 AM
> To: 'Andrew Newton'
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: 
> [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitals
ignatures)
> 
> Unless you can show that this is significantly different from 
> the current situation where you DO get suspicious data, and 
> we DO handle it satisfactorily, then I believe that we know 
> the cure won't be worse than the disease.  The benefit is 
> known, and we have experience that the downside is not harmful.  
> 
> Your suggestion that only "accredited" VSPs can send calls to 
> PSAPs is unworkable, although, again, there can be some 
> suspicion associated with calls originating from an entity 
> not known to the PSAP.  However, that has nothing to do with 
> the problem at hand, since the VSP doesn't supply location, 
> the access network does.
> 
> Brian
> 
> > > In all of this discussion, you seem unconvinced that the 
> 9-1-1 call 
> > > taker can deal with information that is marked 
> suspicious, but may 
> > > be correct.
> > > This happens already, they do handle it okay, and they are 
> > > comfortable with information that may or not be correct.  
> A typical 
> > > example is that the ALI screen says one thing, the caller 
> insists on 
> > > another.  This is suspicious, but permitted.  The response will 
> > > always go to where the caller said to go.
> > > There will be some follow up to determine how the discrepancy 
> > > happened if it turns out the caller was right.
> > >
> > > We're chasing our tail on this, and we need to figure a 
> way out.  I 
> > > get that there are people who don't believe we get a sufficiently 
> > > good defense to an acknowledged threat out of signing location.  
> > > There are a group of us who think we do.  Those of us who 
> think so 
> > > readily agree that unsigned location can be valid.  However, we 
> > > think the mechanism will effectively deter a very large class of 
> > > not-highly-skilled and not-well-financed attackers.
> > >
> > > The largest problem continues to be that we are very 
> significantly 
> > > weakening the security of location as we move to the 
> geopriv way of 
> > > doing things.
> > > What used to be locked inside a wireline/wireless 
> carrier's domain, 
> > > with no access by end users is turning into an end user 
> controlled 
> > > environment.
> > > We're opening a huge security hole.  We need some effective 
> > > strategies to minimize this hole.  We can't close it as 
> securely as 
> > > it was.  We think signatures are one way to significantly 
> help.  You 
> > > don't agree, I get it, but it sure would help if you had a better 
> > > way.  You are saying "no, no no"
> > >>> signed/fail-signed location, be suspicious before dispatching. 
> > >>> Post- call investigation is required.
> > >>>
> > >>> signed location, process the call and report the error 
> afterward 
> > >>> to the location source (presumably the LIS operator).
> > >>
> > >> Guy,
> > >>
> > >> cause both of those problems, yet one type of screw up is 
> > >> considered suspicious while the other type is not.  From 
> a security 
> > >> perspective, this opens up a social engineering attack... the 
> > >> caller needs no technical skill to defeat the signed 
> location.  All 
> > >> they need to do is just verbally disagree with it.
> > >>
> > >> -andy

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 7 Mar 2007 13:32:05 -0500

Probably could be made to work I suppose.  It has the same basic issues of
creating a PKI.  The PSAP has to trust accessprovider.net, it has to know
that the URI is actually the LIS at accrssprovider.net, and then it can use
the pseudorandom credential to ask acccessprovider.net if the LO is genuine.
I'd guess we would be better off just using a location reference though.

Brian

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2007 12:41 PM
> To: 'Brian Rosen'
> Cc: [email-masked]
> Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-
> LOdigitalsignatures)
> 
> Brian,
> 
> What if.......
>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 7 Mar 2007 13:39:23 -0500

> I'd guess we would be better off just using a location reference  

That's an interesting thought.  The channel security of the  
dereference means that you don't have to sign the location to trust it.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 7 Mar 2007 13:53:54 -0500

Yes, it works.  I don't think it's any better or worse than signing the
location value, but the operations required (dereference at every step) is a
pain.  It's functional.  Consider that the TLS operation needs the very same
cert that you would use to sign, the crypto operations are roughly similar,
and the security is pretty much the same.

Let's look at the cases you seem to care about: enterprise and Marc
Linsner's boat-as-access-network.

The enterprise can sign a cert or use it's cert to create a TLS connection.
To trust it, the cert it uses has to be signed by someone you trust.
Signatures have the same characteristics as TLS.  If it won't accept a TLS
(or only offers digest authentication) then you could be suspicious,
although you would proceed.

The boat is unlikely to have a cert you trust for either TLS or signing.
Best you could do is to verify that the domain is owned by the signer, if
the cert was in the DNS.

I'd rather have a signed value.

Brian

________________________________________
From: Andrew Newton [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 1:39 PM
To: Brian Rosen
Cc: 'Marc Linsner'; [email-masked]
Subject: Re:
[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

That's an interesting thought. The channel security of the dereference means
that you don't have to sign the location to trust it.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 7 Mar 2007 14:01:32 -0500

> and the security is pretty much the same.

No.  You missed one crucial and important operation: data  
canonicalization.  Signing the data requires it, using TLS does not.   
And replay attacks can be thwarted.  Plus, it isn't patent encumbered.

> Best you could do is to verify that the domain is owned by the  

It offers no new trust relationship, that is correct.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 7 Mar 2007 14:11:31 -0500

> 
> > Yes, it works.  I don't think it's any better or worse than signing 
> > the location value, but the operations required 
> (dereference at every
> > step) is a
> > pain.  It's functional.  Consider that the TLS operation needs the 
> > very same cert that you would use to sign, the crypto 
> operations are 
> > roughly similar, and the security is pretty much the same.
> 

And all machinery is in-place, from a geopriv perspective.

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 7 Mar 2007 14:21:11 -0500

Brian,

in-line...

> 
> Yes, it works.  I don't think it's any better or worse than 
> signing the location value, but the operations required 
> (dereference at every step) is a pain.  It's functional.  
> Consider that the TLS operation needs the very same cert that 
> you would use to sign, the crypto operations are roughly 
> similar, and the security is pretty much the same.

Why dereference at every step? If l-by-v is supplied, you only dereference
the provided-by uri as an 'authentication' of the presented value.  IOW, use
the provided-by uri when desired, it's not required.  I don't think any
intermediary routing proxy would need to dereference anything when l-by-v is
supplied.  Besides, why is dereferencing l-by-r any bigger pain when chasing
certs?

-Marc- 

> 
> Let's look at the cases you seem to care about: enterprise 
> and Marc Linsner's boat-as-access-network.
> 
> Signatures have the same characteristics as TLS.  If it won't 
> accept a TLS (or only offers digest authentication) then you 
> could be suspicious, although you would proceed.
> 
> Best you could do is to verify that the domain is owned by 
> the signer, if the cert was in the DNS.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 7 Mar 2007 14:51:16 -0500

We crossed signals.  I thought why not just use lbyr instead of lbyv with an
lbyr as a provided-by.  Then you do have to dereference at every step.

Including an lbyr as the provided by in a value gets you both the value and
the lbyr.  If you have both, then you can indeed use the value to route and
display, and use the reference to validate whenever you want to.

Brian

> Sent: Wednesday, March 07, 2007 2:21 PM
> To: 'Brian Rosen'; 'Andrew Newton'
> Cc: [email-masked]

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 7 Mar 2007 17:15:54 -0600

No - I mean the source of the "location information" - not the source of
the call.

Cheers,

Martin

________________________________

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, 8 March 2007 9:46 AM
To: Dawson, Martin; 'Andrew Newton'
Cc: [email-masked]; 'Marc Linsner'
Subject: RE:
[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

Umm, source identity checking won't work.  The identity the LIS
understands may not be the identity in the call (because, for example a
NAT or VPN is in the path).  The endpoint may have a valid location or
reference to give to the calling network, but you can't check that the
identity related to the location is the same as that in the call.  We
could come up with other identities that could be used, but the one we
keep talking about (IP Address) won't work.  We would need to do some
kind of shared secret processing between the triad of the LIS, the
endpoint and the calling network.  That could prove that the entity
getting the location was the same entity sending the call.

Brian

________________________________

From: Dawson, Martin [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 4:55 PM
To: Andrew Newton; Brian Rosen
Cc: [email-masked]; Marc Linsner
Subject: RE:
[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

Gee - I got bagged out for suggesting that the dereferencing mechanism
obviated the concern about temporal and identity integrity for location
information quite some time ago. Must be OK now.

Dereferencing does remove the concerns with respect to knowing that the
location really does apply now (temporal) and that it is applicable to a
specific end-device (identity) - which addresses the main replay
concerns. The other component of location dependability is the "source
identity". That is, that the LIS operator is a recognised and trusted
access operator. This can be achieved by some independent certificate
exchange process - or it could be achieved just by having the
dereferencer request a signed location anyway; that would be the same
process for the LIS on the northbound and southbound interfaces.

Cheers,

Martin

________________________________

From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, 8 March 2007 5:39 AM
To: Brian Rosen
Cc: [email-masked]; 'Marc Linsner'
Subject: Re:
[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

That's an interesting thought.  The channel security of the dereference
means that you don't have to sign the location to trust it.

-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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Andrew Newton <[email-masked]>
Date: Wed, 7 Mar 2007 17:18:00 -0500

On Mar 7, 2007, at 4:56 PM, Dawson, Martin wrote:

> What's the patent encumbrance? Can someone enlighten me?

http://www1.ietf.org/mail-archive/web/geopriv/current/msg02505.html

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 7 Mar 2007 15:55:18 -0600

Cheers,

Martin

 

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 7 Mar 2007 17:45:42 -0500

Umm, source identity checking won't work.  The identity the LIS understands
may not be the identity in the call (because, for example a NAT or VPN is in
the path).  The endpoint may have a valid location or reference to give to
the calling network, but you can't check that the identity related to the
location is the same as that in the call.  We could come up with other
identities that could be used, but the one we keep talking about (IP
Address) won't work.  We would need to do some kind of shared secret
processing between the triad of the LIS, the endpoint and the calling
network.  That could prove that the entity getting the location was the same
entity sending the call.

Brian

  _____  

Dereferencing does remove the concerns with respect to knowing that the
location really does apply now (temporal) and that it is applicable to a
specific end-device (identity) - which addresses the main replay concerns.
The other component of location dependability is the "source identity". That
is, that the LIS operator is a recognised and trusted access operator. This
can be achieved by some independent certificate exchange process - or it
could be achieved just by having the dereferencer request a signed location
anyway; that would be the same process for the LIS on the northbound and
southbound interfaces.

Cheers,

Martin

  _____  

 

-andy

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------
[mf2]

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 7 Mar 2007 15:35:15 -0600

Actually, I don't see how the question of "accredited" VSPs is pertinent
to this issue to begin with (and I mean apart from the fact that this is
exactly the sort of constraint I've been told is anathema to the IETF
and that a US policy is being quoted as a generic basis for
decision-making - must be a goose and gander thing).

Accredited VSPs have some linkage to the subscriber identity - they can
apply whatever audit trail they can to who it is that is making the
calls. They can do nothing about the trustability of the location
information. Oh - unless you'd like to go down the 3GPP[2]/IMS route and
say that VoIP calls can only be made from your home network or from a
roaming partner network (forget being able to use arbitrary hot spots,
municipal WiFi, or hotel broadband connections - that would rule out,
say, Skype and Vonage) - so VoIP is just traditional cellular with an IP
bearer for the voice?

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, 8 March 2007 3:36 AM
To: 'Andrew Newton'
Cc: [email-masked]; [email-masked]; Dawson, Martin;
[email-masked]
Subject: RE:

Unless you can show that this is significantly different from the
current
situation where you DO get suspicious data, and we DO handle it
satisfactorily, then I believe that we know the cure won't be worse than
the
disease.  The benefit is known, and we have experience that the downside
is
not harmful.  

calls originating from an entity not known to the PSAP.  However, that
has

Brian

> > comfortable with
> > strategies to
Post-
> >> cause both of those problems, yet one type of screw up is
considered

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 7 Mar 2007 15:56:37 -0600

Cheers,
Martin

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, 8 March 2007 6:02 AM
To: Brian Rosen
Cc: [email-masked]; 'Marc Linsner'
Subject: Re:

On Mar 7, 2007, at 1:53 PM, Brian Rosen wrote:

> very same

> accept a TLS

-andy

---

From: Randall Gellens <[email-masked]>
Date: Wed, 7 Mar 2007 17:35:58 -0800

>  access by end users is turning into an end user controlled environment.

Well-said.

(This is, of course, a general problem occurring in different areas 
as domains shift to IP.)

>  signatures are one way to significantly help.

Speaking personally, I'm undecided how effective the proposed 
signature mechanisms will be.  I'm also concerned that techniques 
might be selected because they are known to us and thus fairly easy 
to add, as opposed to being effective.  I'm not saying that's the 
case here, but I'm not convinced it isn't.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The best way to have a good idea is to have lots of ideas.
                                           --Linus Pauling

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 7 Mar 2007 21:00:30 -0500

As a side note, the 'accredited' thing is a red herring, either way.  
Signed location information is only meaningful if the location signer  
is 'accredited', i.e., known to be reputable, to the PSAP. After all,  
anybody, with a stolen credit card if necessary, can buy a  
certificate, based solely on possession of a domain name, from  
reputable CAs. That certificate can be used to sign any location  
information. Thus, signing is only meaningful if the signer is known  
and accountable.

Now, it may well be that the number of signers is lower or more  
easily knowable in one or the other case, but the principle is the  
same. We have gone through the 'who can sign' before, so I won't  
repeat that particular discussion.

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 7 Mar 2007 21:09:44 -0600

I certainly agree that it's a generic issue Randy. The Internet creates
a decoupling that didn't exist previously and more, not less,
applications will rely on certificate and other private key based
mechanisms. Any of the objections being raised against its use for
location dependability could be raised against any other solution that
uses certs. It can only be a matter of degree between any given case -
and that's a very subjective distinction.

The thing is, it's the state of the art. I'm not aware of any solution
to the general problem that represents a quantum leap and I'm not aware
of one being on the horizon. If somebody is sitting on a better
solution, then it would be great to hear from them. In the mean time,
though, the state of the art is what we can offer.

Cheers,
Martin

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Thursday, 8 March 2007 12:36 PM
To: Brian Rosen; 'Andrew Newton'; [email-masked]
Cc: [email-masked]; Dawson, Martin; [email-masked]
Subject: RE:
[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignature
s)

Well-said.

strategies to

---

From: Andrew Newton <[email-masked]>
Date: Wed, 7 Mar 2007 23:38:47 -0500

On Mar 7, 2007, at 9:00 PM, Henning Schulzrinne wrote:

> As a side note, the 'accredited' thing is a red herring, either  
> way. Signed location information is only meaningful if the location  
> signer is 'accredited', i.e., known to be reputable, to the PSAP.  
> After all, anybody, with a stolen credit card if necessary, can buy  
> a certificate, based solely on possession of a domain name, from  
> information. Thus, signing is only meaningful if the signer is  
> known and accountable.
>

As you have described it, I agree.  However, what I've heard in NENA  
meetings is that accreditation would be more than just a public  
cert.  I suspect that there are a lot more mechanics around that than  
have been uncovered, and NENA will find out that they will need to be  
their own CA -- which I do not think they intend.

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 7 Mar 2007 23:22:17 -0600

NENA identified the Valid Emergency Services Authority (VESA) agency as
part of the i2 architecture. It was already acknowledged that NENA was
one candidate for providing the VESA function - there are numerous other
possibilities including authorized commercial enterprise. At the TDC/ODC
in Nashville in January, I explicitly asked the chair of the
"certification committee" whether there was a possibility that they
could form the basis for VESA - they acknowledged that they could,
though it's not decided by any means. The main goal of the
certification/accreditation committee is to provide a set of processes
and standards by which the various entities in the emergency
architecture (access providers, VoIP providers, VPC operators, ESGW
operators, ALI operators, PSAPs....) can be assessed for satisfactory
compliance to the requirements of the emergency industry. It's an
independent audit of capabilities including infrastructure and
processes. There is no decision about what the implications of being
"accredited" are yet. It establishes a benchmark for capabilities - the
implications may eventually be defined by regulatory bodies or through
individual industry body policy - or maybe it'll be left to the market
to decide whether they want to sign up with "NENA preferred" providers
or not.

The intent of i2 is that the LIS certificate used for signing location
is, in turn, signed by VESA. Getting a certificate from VESA is not just
a case of whacking down a credit card.

Cheers,

Martin

From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, 8 March 2007 3:39 PM
To: Henning Schulzrinne
Cc: Dawson, Martin; GEOPRIV
Subject: Re:
[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

As a side note, the 'accredited' thing is a red herring, either way.
Signed location information is only meaningful if the location signer is
'accredited', i.e., known to be reputable, to the PSAP. After all,
anybody, with a stolen credit card if necessary, can buy a certificate,
based solely on possession of a domain name, from reputable CAs. That
certificate can be used to sign any location information. Thus, signing
is only meaningful if the signer is known and accountable.

Now, it may well be that the number of signers is lower or more easily
knowable in one or the other case, but the principle is the same. We
have gone through the 'who can sign' before, so I won't repeat that
particular discussion.

As you have described it, I agree.  However, what I've heard in NENA
meetings is that accreditation would be more than just a public cert.  I
suspect that there are a lot more mechanics around that than have been
uncovered, and NENA will find out that they will need to be their own CA
-- which I do not think they intend.

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 7 Mar 2007 23:29:42 -0600

Wow - what a surprise, these just happen to be patents with my name on
them; though they are not owned by me or my current employer.

US2006161967

Is about transitive trust relationships and represents no encumbrance on
the use of digital signatures for location integrity. It might mention
this but that is as context and not as part of a claim. In fact, if
anybody wants, I can provide public disclosed material from NENA
meetings that discuss digital signatures for location integrity and
which predates this patent. This demonstrates the patent can't imply any
encumbrance because said prior public disclosure would invalidate any
claim.

US2006135177

This presents an architecture for privacy control and is not related to
location integrity or digital signatures at all.

Does that address the question of whether there is any IPR encumbrance
on digital signatures for location?

Cheers,

Martin

From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, 8 March 2007 9:18 AM
To: Dawson, Martin
Cc: Brian Rosen; [email-masked]; Marc Linsner
Subject: Re:
[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

-andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 8 Mar 2007 00:38:34 -0500

On Mar 8, 2007, at 12:29 AM, Dawson, Martin wrote:

> Wow – what a surprise, these just happen to be patents with my name  
> on them; though they are not owned by me or my current employer.
Indeed.
> US2006161967
>
> Is about transitive trust relationships and represents no  
> encumbrance on the use of digital signatures for location  
> integrity. It might mention this but that is as context and not as  
> part of a claim. In fact, if anybody wants, I can provide public  
> disclosed material from NENA meetings that discuss digital  
> signatures for location integrity and which predates this patent.  
> This demonstrates the patent can’t imply any encumbrance because  
> said prior public disclosure would invalidate any claim.
Knowledge of prior art by a patent inventor is probably something  
that should be taken up with the patent office.
> Does that address the question of whether there is any IPR  
> encumbrance on digital signatures for location?
Notice from the patent holder would be much more satisfactory.

-andy

---

From: Ted Hardie <[email-masked]>
Date: Wed, 7 Mar 2007 21:41:16 -0800

At 9:00 PM -0500 3/7/07, Henning Schulzrinne wrote:
>As a side note, the 'accredited' thing is a red herring, either way. Signed location information is only meaningful if the location signer is 'accredited', i.e., known to be reputable, to the PSAP. After all, anybody, with a stolen credit card if necessary, can buy a certificate, based solely on possession of a domain name, from reputable CAs. That certificate can be used to sign any location information. Thus, signing is only meaningful if the signer is known and accountable.

As Steve Bellovin has put it:  "A general-purpose CA will protect you from anyone
that they won't take money from".

>Now, it may well be that the number of signers is lower or more easily knowable in one or the other case, but the principle is the same. We have gone through the 'who can sign' before, so I won't repeat that particular discussion.
>

What we still don't seem to have is common understanding of how the threat model has
changed.  For the purposes of DDOS, folks understand very well how the change in
access models has changed the threat model:  in the previous system the
access network topology circumscribed who could send calls to a PSAP,  in a way
that related fairly well to local geography; that is no longer true for the new access
network model, and the result is we now need to manage a different threat
(as the pool of attackers is higher and the ddos risk higher). 

But the same change has a consequence for trust relationships between
network providers and PSAP:   where the number of network providers was
bounded, basically anyone can now put up an access network that has sufficient
to allow access to a VSP.  Extending trust to the access networks in that model
is difficult, time-consuming, and either market-limiting or so weak as to be
nearly useless.  We need to manage that change.  Doing so by adding
cryptographic mechanisms *does no good if they do not reflect the trust
relationships*. 

Define the trust relationships first, and it will get a lot easier to make the right
choice of mechanism.  Choosing a mechanism and then forcing the external
parties to tailor their relationships to the mechanism is procrustean programming
of the worst sort, and it tends to leave the attackers lots of room to wiggle in.

				Ted

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 7 Mar 2007 23:43:20 -0600

> Knowledge of prior art by a patent inventor is probably something  

No - you miss the point again. The patent office won't be interested
because the patent isn't about the thing you're suggesting it represents
an encumbrance on. The prior art is not pertinent to the invention; it's
pertinent to the topic that we've been discussing. I'm emphasising that
they are two different things.

> Notice from the patent holder would be much more satisfactory.

I believe that's been pursued ad nauseum and the ball is certainly in
the owner's court if they want to say something.

Cheers,
Martin

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, 8 March 2007 4:39 PM
To: Dawson, Martin
Cc: Brian Rosen; [email-masked]; Marc Linsner
Subject: Re:

On Mar 8, 2007, at 12:29 AM, Dawson, Martin wrote:

> Wow - what a surprise, these just happen to be patents with my name  
Indeed.
> This demonstrates the patent can't imply any encumbrance because  

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 8 Mar 2007 00:04:29 -0600

I'd like to challenge the following premise:

"... where the number of network providers was
bounded, basically anyone can now put up an access network that has
sufficient to allow access to a VSP."

In fact, the number of physical public access infrastructure providers
is comparable for Internet access as it is for PSTN, including cellular.
Until somebody invents and deploys subspace internet access technology,
the same constraint of geographic co-location applies just as it did for
the PSTN.

(if this degenerates into the Pringle can debate again, then I'd refer
people to the NENA archives)

Including ISPs certainly blows the number out but there is no strict
requirement for them to be included in the trust model - any more than
there is for the PSAP to know that a cellular call that appears to come
from the Verizon network is really one coming from a subscriber of any
one of a squillion MVNOs - MVNOs who don't actually own their own access
infrastructure.

As long as the location is signed by a trusted public access
infrastructure provider then dependability is established. The
infrastructure operator has the audit records that show who the actual
ISP for a given location was. The recent liaison document on location
acquisition protocols that came from ESIF described this relationship
model between ISPs and infrastructure providers. It's a recommended
read.

If we wanted to extend the PIDF-LO to include a chain of provider
identities so the location recipient had direct access to a signed
record of provider identities then that's certainly a good option to
discuss.

Cheers,
Martin

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Thursday, 8 March 2007 4:41 PM
To: Henning Schulzrinne; Dawson, Martin
Cc: GEOPRIV
Subject: Re:

As Steve Bellovin has put it:  "A general-purpose CA will protect you
from anyone
that they won't take money from".

What we still don't seem to have is common understanding of how the
threat model has
changed.  For the purposes of DDOS, folks understand very well how the
change in
access models has changed the threat model:  in the previous system the
access network topology circumscribed who could send calls to a PSAP,
in a way
that related fairly well to local geography; that is no longer true for
the new access
network model, and the result is we now need to manage a different
threat
(as the pool of attackers is higher and the ddos risk higher). 

But the same change has a consequence for trust relationships between
network providers and PSAP:   where the number of network providers was
bounded, basically anyone can now put up an access network that has
sufficient
to allow access to a VSP.  Extending trust to the access networks in
that model
is difficult, time-consuming, and either market-limiting or so weak as
to be
nearly useless.  We need to manage that change.  Doing so by adding
cryptographic mechanisms *does no good if they do not reflect the trust
relationships*. 

Define the trust relationships first, and it will get a lot easier to
make the right
choice of mechanism.  Choosing a mechanism and then forcing the external
parties to tailor their relationships to the mechanism is procrustean
programming
of the worst sort, and it tends to leave the attackers lots of room to
wiggle in.

				Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 8 Mar 2007 09:02:08 -0500

All I meant to say is that regardless of whether the LO is signed,  
the caller ID is signed or the LIS identity is verified via some  
reference mechanism, you will need an "accreditation" mechanism,  
i.e., a mechanism where an entity approved by the local authorities  
restricts who can sign. The signature or TLS mechanics are the easy  
part; the logistical and political arrangements are probably beyond  
the expertise of the IETF and likely highly dependent on the  
jurisdiction, given that they have obvious intersections with telecom  
competition, privacy laws and a host of other non-technical issues.

On Mar 7, 2007, at 11:38 PM, Andrew Newton wrote:

>> way. Signed location information is only meaningful if the  
>> location signer is 'accredited', i.e., known to be reputable, to  
>> the PSAP. After all, anybody, with a stolen credit card if  
>> necessary, can buy a certificate, based solely on possession of a  
>> domain name, from reputable CAs. That certificate can be used to  
>> sign any location information. Thus, signing is only meaningful if  
>> the signer is known and accountable.
>>
> As you have described it, I agree.  However, what I've heard in  
> NENA meetings is that accreditation would be more than just a  
> public cert.  I suspect that there are a lot more mechanics around  
> that than have been uncovered, and NENA will find out that they  
> will need to be their own CA -- which I do not think they intend.
>
> -andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 8 Mar 2007 09:05:43 -0500

The plan for a while is that NENA will create a Certificate Authority and
issue certs to 9-1-1 Authorities.  In the i2 plan, the CA also issues certs
to the specialized service providers that assist in processing calls on the
existing network, and they in turn could issue certs to carriers they supply
services to.  In the i3 (all-IP) environment, this has not yet been decided,
but in general, a local 9-1-1 authority knows the local access network
providers.  Enterprise is a problem.  I have some ideas, but they are just
ideas.

The i3 specs say calls can come from anyone, including the Internet.  They
ask for TLS connections, and I expect will recommend VPN or dedicated IP
paths to what we call the Emergency Services IP network for carriers who
deliver significant numbers of calls to the ESInet, probably at something
like the state level.  There will be certs involved in those.

Brian

  _____  

From: Andrew Newton [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 11:39 PM
To: Henning Schulzrinne
Cc: GEOPRIV; Dawson, Martin
Subject: Re:
[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

As a side note, the 'accredited' thing is a red herring, either way. Signed
location information is only meaningful if the location signer is
'accredited', i.e., known to be reputable, to the PSAP. After all, anybody,
with a stolen credit card if necessary, can buy a certificate, based solely
on possession of a domain name, from reputable CAs. That certificate can be
used to sign any location information. Thus, signing is only meaningful if
the signer is known and accountable.

Now, it may well be that the number of signers is lower or more easily
knowable in one or the other case, but the principle is the same. We have
gone through the 'who can sign' before, so I won't repeat that particular
discussion.

As you have described it, I agree. However, what I've heard in NENA meetings
is that accreditation would be more than just a public cert. I suspect that
there are a lot more mechanics around that than have been uncovered, and
NENA will find out that they will need to be their own CA -- which I do not
think they intend.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 8 Mar 2007 09:29:34 -0500

> they are two different things.

Actually, if you have information on prior art related to these  
patents or any IPR relevant to GEOPRIV, it would be helpful if you  
share that information with the working group.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 8 Mar 2007 09:37:40 -0500

Brian,
 
'a local 9-1-1 authority knows the local access network providers'
 
Do you actually believe this going forward?
 
Yes, there is the assertion made about a limited set of physical access
providers and I agree that NYC 9-1-1 authority probably knows about the <10
legacy providers.  But a 10 second search for public Internet access in NYC
produces nothing short of hundreds of providers.  As you state, Enterprise
is a problem.  Are you considering the 100s of providers my search produced
as Enterprise?
 
-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 8 Mar 2007 09:39:30 -0500

The one thing you miss in this discussion is that it's a LOCAL access
provider providing location to a LOCAL PSAP.  That is what makes this
situation different from the general case.  Yes, anyone can put up an access
network, but it's always LOCAL to the PSAP.

Also, we have provided a test capability.  This will tell an end user that
the location is somehow not pluperfect in advance of needing it.  

Again, I ask that instead of saying "no, no, no" you instead somehow say "no
not that, use this".  You acknowledge we have a problem.  We need solutions.
We'll acknowledge that it's not going to be great, because the world has
changed and the threats have changed, but it should be possible to put
sufficient controls in place to make the threat manageable.

Brian

> Sent: Thursday, March 08, 2007 12:41 AM
> Subject: Re:[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-
> LOdigitalsignatures)
> 
> certificate can be used to sign any location information. Thus, signing is
> only meaningful if the signer is known and accountable.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 8 Mar 2007 09:42:59 -0500

I think the key word below is "public" in the phrase "public access
infrastructure".  The reality of the Internet is that not all access is
public.  That limits what we can do.

It's still local.  That helps a lot.

Brian

> Sent: Thursday, March 08, 2007 1:04 AM
> To: GEOPRIV

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 8 Mar 2007 09:53:56 -0500

We're going to require ALL access providers to provide location.  ALL of
them.  It's not unreasonable to ask them to get a cert from the local 9-1-1
authority (or some contractor they appoint) as part of that obligation.  We
probably are going to have regulation to make "ALL" work.  Getting the cert
can be part of that.  There will be extenuating circumstances.  They will
create exploitable holes.  I think we can manage that reasonably well, but
some threat will remain.

Brian.

  _____  

From: Marc Linsner [mailto:[email-masked]] 
Sent: Thursday, March 08, 2007 9:38 AM
To: 'Brian Rosen'
Cc: 'GEOPRIV'
Subject: RE:
[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

Brian,

-Marc-

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 08 Mar 2007 10:40:11 -0500

I think what this thread is leading to is that:

-- national/regional regulatory authorities will impose regulations that imply a 
particular technical means of defence against fraudulent calls

-- that means national/regional rather than IETF standardization of these 
technical means

-- the role of the IETF is limited to provision of the toolkit and making sure 
they don't get in the way.

Brian Rosen wrote:
> From: Marc Linsner [mailto:[email-masked]] Sent: Thursday, March 08, 2007
> 9:38 AM To: 'Brian Rosen' Cc: 'GEOPRIV' Subject: RE:
> produces nothing short of hundreds of providers.  As you state, Enterprise is
> a problem.  Are you considering the 100s of providers my search produced as
> Enterprise?
> 
> 
> 
> -Marc-
> 
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 8 Mar 2007 12:08:37 -0800

At 9:53 AM -0500 3/8/07, Brian Rosen wrote:
>We're going to require ALL access providers to provide location.  ALL of them.  It's not unreasonable to ask them to get a cert from the local 9-1-1 authority (or some contractor they appoint) as part of that obligation.  

I would appreciate your stating who "we" is in the sentence above.  I assume it
is someone with the regulatory power in a specific jurisdiction mentioned below,
but I'd rather have a clear statement as to whom.

>We probably are going to have regulation to make "ALL" work.  Getting the cert can be part of that.  There will be extenuating circumstances.  They will create exploitable holes.  I think we can manage that reasonably well, but some threat will remain.
> 
>Brian.

Martin doesn't believe that I can stand up an access network sufficient to reach
a VSP, and I think he believes that my upstream is the "real" network.  Do you agree,
and would it be the upstream of the enterprise, SOHO, and home networks who
gets this requirement?  This is important because it changes how the trust
model works--it means the PSAP has to have relationships with transit
networks, rather than access networks, and it will have regulatory power
to extend that trust from the transit network to the access network (presumably
through the customer relationship, by presuming that involves payment even
if the access network provides free service).  Does that fit the model, as
you understand it?

Note that multi-homing the enterprise and other access networks is both
burgeoning business and of serious concern to other parts of the IETF.  Each
one of those that gets PI space and starts making its own BGP announcement
becomes something like a transit upstream, but isn't exactly the same. 
Where do they fit?  Does taking on additional upstream turn you into someone
who has to meet this requirement, or does it only occur if you carry prefixes
originated by someone else?

As Marc has noted, lots of enterprises may fall into this.  An enterprise may
have multiple campuses, with multiple upstream providers (either per
campus, in a mesh, or with a star topology with multiple upstreams from
the center).  Getting them to provide location is one thing.  Getting them
to associate the topology, location, and the right signing authority for
a specific 911 authority is far more complex.

I realize that this comes across as failing your "tell us what to do instead"
test, but I'm trying to get across that "make it act like it used to" is a requirement
that creates very serious burdens.   If the requirement is to allow
calls from anyone (and that is the requirement, as I understand you),
there may be a fundamental trade-off between meeting that requirement
and the security concerns here. 

				Ted

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 8 Mar 2007 17:13:35 -0600

Hear hear.

There are continually arguments about what we are requiring the
implementors to implement. Despite the undoubted brain power in the
room, it's not going to be possible to assess the needs and
applicability for every emergency jurisdiction in the world and come up
with an exact fit for everyone. Not every jurisdiction may require
location from access operators, not every one of those may require it be
signed, and those that do will establish their own organizations and
processes around certificate management. 

The toolkit to build to their regional policies is exactly what we are
giving them.

Cheers,
Martin

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]] 
Sent: Friday, 9 March 2007 2:40 AM
To: Brian Rosen
Cc: GEOPRIV; Marc Linsner
Subject: Re:

-- national/regional regulatory authorities will impose regulations that
imply a 
particular technical means of defence against fraudulent calls

-- that means national/regional rather than IETF standardization of
these 
technical means

-- the role of the IETF is limited to provision of the toolkit and
making sure 
they don't get in the way.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 8 Mar 2007 18:35:52 -0500

Well, no, I don't think so.  If I look at the skill set available in, say,
NENA, they can't make good technical judgments on this level of security
mechanisms.  The IETF really has the right expertise to do this, and it
should.

It may not specify how to, for example, establish a PKI.  It should specify
the protocols and crypto mechanisms.  We could have options if the rationale
for choosing was explained.

Brian

> Sent: Thursday, March 08, 2007 6:14 PM
> To: Tom-PT Taylor; Brian Rosen

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 8 Mar 2007 19:36:21 -0600

I'm agreeing with you Brian. So - we provide the mechanisms with the
crypto set at state of the art etc. Then each jurisdiction gets to
decide whether signatures are appropriate to their environment.

We don't make a unilateral decision that signatures are not appropriate
for emergency service environments globally and then exclude that tool
from the kit.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 9 March 2007 10:36 AM
To: Dawson, Martin; 'Tom-PT Taylor'
Cc: 'GEOPRIV'; 'Marc Linsner'
Subject: RE:

Well, no, I don't think so.  If I look at the skill set available in,
say,
NENA, they can't make good technical judgments on this level of security
mechanisms.  The IETF really has the right expertise to do this, and it
should.

It may not specify how to, for example, establish a PKI.  It should
specify
the protocols and crypto mechanisms.  We could have options if the
rationale
for choosing was explained.

Brian

> > We're going to require ALL access providers to provide location.
ALL
> of
> > them.  It's not unreasonable to ask them to get a cert from the
local
> 9-1-1
> > probably are going to have regulation to make "ALL" work.  Getting
the
> cert
> > create exploitable holes.  I think we can manage that reasonably
well,
> but
> ----------------------
> ----------------------

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 8 Mar 2007 20:56:04 -0600

Hi Ted,

This is a good opportunity to address the specifics of at least one
patent question that's been bandied about in the last day.

Your analysis is excellent and, yes, the question of transitive trust
*can* come up and you've homed in on the large and multi-site campus
scenarios that may lead to this issue.

Again - I'd refer people to the ATIS document that looks at geo-point
and geo-distributed LANs as different LIS environments. I believe the
scenarios can be categorized in a manageable way - as opposed to
throwing up the hands and saying it's all too complicated, let's just
not provide any location dependability mechanism.

An Internet access point may be:

1. On a LAN of a constrained enough nature that the location determined
by the infrastructure provider is of sufficient accuracy. This covers
domestic broadband connections, coffee shop hotspots, and the majority
of shop front enterprises - where the civic address associated with the
service is adequate.

2. Part of a LAN that has an extensive geographical area *and* where it
is important that location be something more precise than the external
provider would determine. This is analogous to the POTS requirement that
exists in at least six US states now, where the owner of the premises is
required to provide emergency call location within, for example, 400 sq
feet and to the right floor for the site.

3. A combination of 1 and 2 where an enterprise is actually multi-site
and each site connects by VPN over the public Internet.

4. A combination of 1 and 2 where the enterprise owns its own
infrastructure across multiple sites - via leased dark fiber and similar
mechanisms that bypass local public Internet carriers.

For (1) there is no additional trust issue. The carrier LIS is the
entity determining location and signing it.

For (2) there is a possible issue. In this case a "campus" LIS is
required that can determine a more precise location than the carrier LIS
is able to. If a client device on this LAN asks for a signed location,
the campus LIS needs a recognized certificate. Alternatively, and this
ladies and gentlemen is what the Nortel patent application US2006161967
covers, the device could ask the campus LIS for a signed location, the
campus LIS could determine the location, then the campus LIS could send
an assertion request to the carrier LIS asking it to sign that location.
This requires an explicit transitive trust relationship from the device
through the campus LIS to the carrier LIS with the result being a
location determined and signed based on the trust relationship between
the campus LIS operator and the carrier LIS operator.

I have an email from Brian Rosen from about three years ago saying "nope
this won't work". However, I sense Brian's thinking has moved on a good
deal since then so perhaps he has a different opinion now. In any case,
the purpose was to provide a mechanism whereby the certificate authority
did not have to evaluate every enterprise with a large enough premises
to justify requiring a certificate but, instead, place the
responsibility on the public carrier to provide the proxy-signature and
assertion service on behalf of those enterprises.

For (3) the requirement is that each enterprise site use the local
public carrier LIS before sending any location information, for example,
through the centralized SIP server. Each site then becomes a particular
case of (1) or (2).

For (4) the problem is that there is no local carrier involved to vet
the location. We're talking about *big* enterprises here (and probably
decreasingly so since site interconnectivity via VPN on the public
Internet is an increasing trend). Examples are transnationals (GE, IBM
for example) or educational research or other government type networks.
The sites in these networks could get a local carrier connection just
for the purpose of obtaining signed location. Alternatively, these sorts
of enterprises are big enough and ugly enough to warrant being issued
and securely managing their own certificates. For truly global examples,
I suggest they would need to obtain certificates from each national
jurisdiction that they operate within and ensure they used the correct
one whenever they sign location - generally this would only mean that
the LIS in a particular national location would need the local
jurisdiction certificate.

Going back to the analogy mentioned in the description of 2, scenario 4
has had this issue for telephony VPNs for many years. Where all sites
share a common PABX, emergency calls do not work where the only public
PSTN access is via the central PABX trunks. Location information, and
routing, ends up being compromised. For large companies, the option was
generally to have a local switch that directed emergency calls via a
local phone service. This is the equivalent to the option above, of
having a local Internet access for getting local provider signed
location. In the old days, and today, this ancillary public service
connection was/is typically used for backup anyway.

Note that "the number of upstream providers" is not an issue - any given
site is only concerned with who the upstream provider at that site is.

Cheers,
Martin

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Friday, 9 March 2007 7:09 AM
To: Brian Rosen; 'Marc Linsner'
Cc: 'GEOPRIV'
Subject:
RE:[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatur
es)

At 9:53 AM -0500 3/8/07, Brian Rosen wrote:
>We're going to require ALL access providers to provide location.  ALL
of them.  It's not unreasonable to ask them to get a cert from the local
9-1-1 authority (or some contractor they appoint) as part of that
obligation.  

I would appreciate your stating who "we" is in the sentence above.  I
assume it
is someone with the regulatory power in a specific jurisdiction
mentioned below,
but I'd rather have a clear statement as to whom.

>We probably are going to have regulation to make "ALL" work.  Getting
the cert can be part of that.  There will be extenuating circumstances.
They will create exploitable holes.  I think we can manage that
reasonably well, but some threat will remain.
>Brian.

Martin doesn't believe that I can stand up an access network sufficient
to reach
a VSP, and I think he believes that my upstream is the "real" network.
Do you agree,
and would it be the upstream of the enterprise, SOHO, and home networks
who
gets this requirement?  This is important because it changes how the
trust
model works--it means the PSAP has to have relationships with transit
networks, rather than access networks, and it will have regulatory power
to extend that trust from the transit network to the access network
(presumably
through the customer relationship, by presuming that involves payment
even
if the access network provides free service).  Does that fit the model,
as
you understand it?

Note that multi-homing the enterprise and other access networks is both
burgeoning business and of serious concern to other parts of the IETF.
Each
one of those that gets PI space and starts making its own BGP
announcement
becomes something like a transit upstream, but isn't exactly the same. 
Where do they fit?  Does taking on additional upstream turn you into
someone
who has to meet this requirement, or does it only occur if you carry
prefixes
originated by someone else?

As Marc has noted, lots of enterprises may fall into this.  An
enterprise may
have multiple campuses, with multiple upstream providers (either per
campus, in a mesh, or with a star topology with multiple upstreams from
the center).  Getting them to provide location is one thing.  Getting
them
to associate the topology, location, and the right signing authority for
a specific 911 authority is far more complex.

I realize that this comes across as failing your "tell us what to do
instead"
test, but I'm trying to get across that "make it act like it used to" is
a requirement
that creates very serious burdens.   If the requirement is to allow
calls from anyone (and that is the requirement, as I understand you),
there may be a fundamental trade-off between meeting that requirement
and the security concerns here. 

				Ted