Subject: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00

From: Andrew Newton <[email-masked]>
Date: Mon, 5 Feb 2007 23:08:13 -0500

All,

This message marks the issuance of a working group last call (WGLC)  
on GEOPRIV's Internet Draft entitled "GEOPRIV Layer 7 Location  
Configuration Protocol; Problem Statement and Requirements" (draft- 
ietf-geopriv-l7-lcp-ps-00.txt).  You may view this document at http:// 
www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-00.txt.

Please post comments and questions to this mailing list no later than  
20 February 2007.

-andy, GEOPRIV co-chair

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

---

From: <[email-masked]>
Date: Thu, 8 Feb 2007 23:29:24 -0500

Hi,

I will take this opportunity to provide comments on this piece of work. I plan to post in small chunks, mostly driven by my reading through the document.

1) My first comment is more semantic and is relative to the choice of "Location Configuration Protocol (LCP)" for the generic term to describe L7-based protocols.

This terminology has been used for a specific protocol proposed within this working group creating ambiguity as to what exactly is being referenced.

Why "configuration"? Aren't we talking about protocols performing "Location Acquisition"?

The word "configuration" does not jive IMO, with the 2 roles described in section 1.

Therefore, I would personally prefer "L7 Location Acquisition Protocol".

2) While the document is relatively clear as to what information it intends to provide, it is unclear as to why it exists and for what purposes. Additional text in the Abstract section and/or in the Introduction stating how this document will be utilized would be very helpful.

More to come. Thanks.

Guy Caron

-----Message d'origine-----
De : Andrew Newton [mailto:[email-masked]] 
Envoyé : 5 février 2007 23:08
À : GEOPRIV WG
Objet : [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00

All,

-andy, GEOPRIV co-chair

---

From: Andrew Newton <[email-masked]>
Date: Fri, 9 Feb 2007 10:32:55 -0500

Guy, thanks for the feedback.  My comment below:

On Feb 8, 2007, at 11:29 PM, [email-masked] wrote:
> 1) My first comment is more semantic and is relative to the choice  
> of "Location Configuration Protocol (LCP)" for the generic term to  
> describe L7-based protocols.
>
> This terminology has been used for a specific protocol proposed  
> within this working group creating ambiguity as to what exactly is  
> being referenced.
>

What do you call a protocol that coordinates measurements from  
different sensors to determine location?  I would think "location  
acquisition protocol" better describes that.  A "location  
configuration protocol" doesn't determine a location, it merely  
configures an IP host with its location, just like an IP host might  
configured with its IP address and domain name.

-andy

---

From: <[email-masked]>
Date: Fri, 9 Feb 2007 11:23:03 -0500

Andrew,

"What do you call a protocol that coordinates measurements from  
different sensors to determine location?"

I would call it a "Measurements Acquisition Protocol" :-). Measurements are not the actual location, only pieces of information that will eventually be used to construct a location. This is quite clear in a DSL environment.

"A "location configuration protocol" doesn't determine a location..."

This is actually well stated at the end of section 1 and I agree that the L7 protocol does not aim at that.

"... it merely configures an IP host with its location..."

This is where the semantic comes into play as it depends on the definition of the word "configuration" in the context. The way I see this, the L7 protocol itself does not configure the VEP but the VEP rather acquires the location first using the L7 protocol so it can configure itself with the piece of information. Now, I could understand the utilization of the word "configuration" in the context of a DHCP-based protocol where the DHCP server pushes the location information to the VEP; it makes it consistent with the concept of DHCP. In the case of a L7 protocol, the VEP pulls the information from a LIS when it requires it.

I don't want to sound too fussy about this but my main concern is really about the utilisation of "LCP" as a generic term and also as a specific proposal. It just creates confusion.

Thanks,

Guy Caron
-----Message d'origine-----
De : Andrew Newton [mailto:[email-masked]] 
Envoyé : 9 février 2007 10:33
À : Caron, Guy (A162859)
Cc : [email-masked]
Objet : Re: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00

-andy

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 10 Feb 2007 21:22:05 +0100

Hi,

thanks for your review. Please find a few responses below:

> Therefore, I would personally prefer "L7 Location Acquisition Protocol".

We have chosen the title of the document based on the title of the 
design team work.
As I stated repeatedly, I cannot get excited about terminology. I am 
happy with anything that is roughly reasonable.

> 2) While the document is relatively clear as to what information it intends to provide, it is unclear as to why it exists and for what purposes. Additional text in the Abstract section and/or in th…
Some folks in the working group it would be very important to work on a 
standardized protocol for requesting and receiving location information 
using an application layer protocol. A few solution proposals have been 
sent to the working group and they received some attention. Then, the WG 
chairs decided to form a design team to investigate the requirements. 
Since the requirements should be motivated and are based on 
architectural aspects we have also documented them.

This is a quite common approach in the IETF to start the work on protocols.

Does my explanation make sense to you?

Ciao
Hannes

---

From: <[email-masked]>
Date: Sat, 10 Feb 2007 21:16:12 -0500

Yes it does, Hannes.

Thanks.

Guy Caron
-----Message d'origine-----
De : Hannes Tschofenig [mailto:[email-masked]] 
Envoyé : 10 février 2007 15:22
À : Caron, Guy (A162859)
Cc : [email-masked]
Objet : Re: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00

Hi,

Ciao
Hannes

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 12 Feb 2007 00:38:55 -0600

I do prefer Location Acquisition Protocol for what's being discussed.

If I applied your definition to the concept of "acquiring" a house,
Andy, it would equate to the process of ordering the materials from
which a house can be built. The processing of acquiring the house hasn't
been completed via that process and neither is it a necessary step for
an entity that is doing the acquiring of the house.

I like the term "location measurement conveyance" for the concept you're
referring to - though the NGES group in ESIF chose "location parameter
conveyance", which I'd still prefer to "location acquisition" as a
label.

I think the term location configuration was chosen so that it resonated
with the proposition of using DHCP but, in any case, as Guy points out
it's also the name of a specific protocol which makes it confusing to
use as a general label.

Mind you, as an aside, I also don't really like the term L7 protocol.
Nominally, any protocol that doesn't provide the function of part of one
more of layers 1-6 of the OSI model is an L7 (application) protocol -
and that doesn't matter whether it is typically carried on top of L2 or
some other layer. I think what we're really talking about is location
acquisition protocols that are nominally used above the networking (L3)
layer, i.e. IP.

Cheers,
Martin

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Saturday, 10 February 2007 2:33 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00

-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]

---

From: <[email-masked]>
Date: Tue, 13 Feb 2007 15:33:55 -0500

It seems to me that many non-working group documents of Geopriv have the potential for a promotion, especially the ones that have been sitting there for months. With official milestones in the range of early 2005, I wonder what the criteria for promoting them to active working group documents are. From my perspective, many core issues inherent to the Geopriv charter are not yet formally addressed through working group documents.

Here is an example I came across, based on a need we had as an emergency service provider, to find a standard way to validate the integrity of provided location data, in order to prevent location forgery. From draft-ietf-geopriv-l7-lcp-ps-00, the need for digital signatures for PIDF-LO documents is clearly acknowledged, with many surrounding issues and counter-measures presented, but a specific signing technique is stated to be out-of-scope of the document. In this context, I find quite relevant to promote draft-thomson-domain-auth-01 to a working group document as it defines a way to perform such signatures using already established standards.

Regards,

Jérôme

-----Message d'origine-----

All,

-andy, GEOPRIV co-chair

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 13 Feb 2007 15:48:56 -0500

I am a proponent of signing location.  I think it provides a worthwhile
level of protection against wholesale forgery of location, but does not
prevent some forms of replay attacks (or stealing a valid location from a
compromised or cooperating device, and representing that as the location
when it isn't).

However, I believe that the signature mechanism must pass through ALL
location configuration and conveyance protocols, which would include
LLDP-MED and DHCP (and, depending on how things work out, SUPL).  The cited
work does not do that.

I also wonder if the extra work involved in passing identity actually helps.
I think forging the identity is as easy as forging the location, and if you
compromise an element, or have an accomplice, then you can masquerade as
another identity.  Some identities can be verified, others cannot.  Couple
that with the necessity that identity not always be revealed when location
is revealed, and you have to question the value of that part of it.

I think a signature by the location source, with a time stamp, provides
substantial protection.  We can make it better, but at what cost, and with
what additional complexity, and with what value.

I do think we should first decide if the threat (trivial forgery) is
significant to do something about it.  I think it is.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, February 13, 2007 3:34 PM
> To: [email-masked]
> Subject: RE: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00 (PIDF-
> LOdigital signatures)
> 
> It seems to me that many non-working group documents of Geopriv have the
> potential for a promotion, especially the ones that have been sitting
> there for months. With official milestones in the range of early 2005, I
> wonder what the criteria for promoting them to active working group
> documents are. From my perspective, many core issues inherent to the
> Geopriv charter are not yet formally addressed through working group
> documents.
> 
> Here is an example I came across, based on a need we had as an emergency
> service provider, to find a standard way to validate the integrity of
> provided location data, in order to prevent location forgery. From draft-
> ietf-geopriv-l7-lcp-ps-00, the need for digital signatures for PIDF-LO
> documents is clearly acknowledged, with many surrounding issues and
> counter-measures presented, but a specific signing technique is stated to
> be out-of-scope of the document. In this context, I find quite relevant to
> promote draft-thomson-domain-auth-01 to a working group document as it
> defines a way to perform such signatures using already established
> standards.
> 
> Regards,
> 
> Jérôme
>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 13 Feb 2007 15:51:01 -0500

On Feb 13, 2007, at 3:33 PM, [email-masked] wrote:

> It seems to me that many non-working group documents of Geopriv  
> have the potential for a promotion, especially the ones that have  
> been sitting there for months. With official milestones in the  
> range of early 2005, I wonder what the criteria for promoting them  
> to active working group documents are. From my perspective, many  
> core issues inherent to the Geopriv charter are not yet formally  
> addressed through working group documents.

Well, we did attempt to update the milestones.  We are currently in  
negotiations with our AD.

The only document that is "lingering" is revised-civic, and I've  
already apologized to the authors for the delay.

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 13 Feb 2007 15:11:24 -0600

I don't believe that placing a requirement on the L7 acquisition protocol that you can only do signatures if they can be supported by LLDP-MED and DHCP is a reasonable thing to do. 

By the definitions that are used in this WG, DHCP and LLDP-MED are sighting protocols. Consequently they are not subject to the same or covered by the requirements being proposed in the L7 Location Acquisition document. Encumbering the L7 solution to extend characteristics to sighting protocols so that they can exhibit behaviours required by other protocols seems absurd. 

I would be happy to say that the L7 acquisition protocol must not preclude the future inclusion and transport of signatures applicable to sighting protocol forms (what ever they may be). You are then free to come up with signature solutions over time if they prove to be required for sighting protocols.

I don't believe that this limitation on sighting protocols should be made to encumber the more feature-rich alternatives, nor should it delay progression of solutions that are ready to go.

Cheers
James

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, 14 February 2007 7:49 AM
> To: [email-masked]; [email-masked]
> LOdigitalsignatures)

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 13 Feb 2007 16:21:46 -0500

I respectfully disagree.

The intention so far is that all location configuration protocols are
equivalent, and the choice is up to the access network provider.  The client
has to deal with them all.  Signatures are not a characteristic of the
protocol, they are a characteristic of a generic solution to the threat.
Further, the signature has to survive the conveyance (meaning at least
sip-location-conveyance).  I am not interested in solving subsets of the
problem.  Either a recipient, like a PSAP, can reasonably depend on getting
a signature in most circumstances, or it can't.  If it gets it sometimes,
it's not useful.  If it gets it almost always, then it is useful, and it can
have reasonable strategies to deploy when it doesn't get one.

There are legitimate cases where the signature will be missing or bad.  It
DOES NOT mean that the location is wrong.  It might be, and the receiver
will have to have a process it follows when that happens.  I don't believe
the mechanism can be made foolproof, but it can be useful.  However, it can
only be useful if the signature is there most of the time.  If only L7 LCP
does it, then it won't.

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Tuesday, February 13, 2007 4:11 PM
> To: Brian Rosen; [email-masked]; [email-masked]
> I don't believe that placing a requirement on the L7 acquisition protocol
> that you can only do signatures if they can be supported by LLDP-MED and
> DHCP is a reasonable thing to do.
> 
> By the definitions that are used in this WG, DHCP and LLDP-MED are
> sighting protocols. Consequently they are not subject to the same or
> covered by the requirements being proposed in the L7 Location Acquisition
> document. Encumbering the L7 solution to extend characteristics to
> sighting protocols so that they can exhibit behaviours required by other
> protocols seems absurd.
> 
> I would be happy to say that the L7 acquisition protocol must not preclude
> the future inclusion and transport of signatures applicable to sighting
> protocol forms (what ever they may be). You are then free to come up with
> signature solutions over time if they prove to be required for sighting
> protocols.
> 
> I don't believe that this limitation on sighting protocols should be made
> to encumber the more feature-rich alternatives, nor should it delay
> progression of solutions that are ready to go.
> 
> Cheers
> James
> 
> 
> 
> > > be out-of-scope of the document. In this context, I find quite
> relevant
> > to

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 13 Feb 2007 16:26:26 -0500

One of the problems of this discussion is that the threat models are  
never quite explained. There are at least two that are of interest  
related to signing:

(1) Human users trying to pretend to be elsewhere. ("Alice, in NYC,  
calls the SF fire department, by swapping signed locations with  
Bob.") I don't consider this attack terribly interesting, due to the  
difficulty of making it scale beyond individual crank calls.

(2) Bots; they can get the real signature for their real location.  
The advantage of signing is that the bot has to be located in the  
PSAP service area, so that this limits the size of the bot army an  
attacker can bring to bear.

We can now just replay the usual discussion again about the  
difficulty of actually creating verifiable signatures, unless  
extremely restrictive assumptions are made on who can operate a LIS.  
The owners of such verifiable signatures can be prioritized, however.

Henning

On Feb 13, 2007, at 3:48 PM, Brian Rosen wrote:

>> have the
>> relevant to

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 13 Feb 2007 16:40:49 -0500

The threat is the first one.  Script kiddie writes a script that gets a call
to 9-1-1 that looks like it comes from somewhere else, resources are
diverted to that location.  You may not consider the problem interesting,
but everyone in the 9-1-1 system I know does.

The second attack is also interesting, but is not the one I think signatures
help with.  The location reported IS the location of the caller.  The caller
itself is bad.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, February 13, 2007 4:26 PM
> To: Brian Rosen
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00 (PIDF-
> LOdigital signatures)
>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 13 Feb 2007 17:28:56 -0500

On Feb 13, 2007, at 4:11 PM, Winterbottom, James wrote:

> sighting protocols. Consequently they are not subject to the same  
> or covered by the requirements being proposed in the L7 Location  
> Acquisition document. Encumbering the L7 solution to extend  
> characteristics to sighting protocols so that they can exhibit  
> behaviours required by other protocols seems absurd.

Exactly what is the distinction between a sighting protocol and a  
location acquisition protocol?

And wouldn't it be valuable to pursue a solution that works with them  
all vs. one that works with just one?

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 13 Feb 2007 17:47:45 -0600

I agree with Brian's assessment here - largely it's about being able to eliminate the ability to routinely *and without exploit* misrepresent your location. Although Henning does highlight how the use of signatures does raise the bar as far as how geographically targeted the exploit has to be.

I cannot agree that the lack of support of this by "non-L7" protocols obviates the ability to have the requirement. It feels like arguing that the legacy must always limit the possible. Certainly the NENA requirements for the acquisition protocol include the ability to do the things that the below-referenced draft mention (that's pretty much the main reason the draft was written).

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 14 February 2007 8:41 AM
To: 'Henning Schulzrinne'
Cc: [email-masked]
Subject: RE: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00 (PIDF-LOdigitalsignatures)

Brian

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Tue, 13 Feb 2007 18:16:34 -0700

Brian -

I just "pulsed" the OGC Working Group that deals with rights management, 
authentication, and associated standards for use with location. There work 
is a bit broader than signatures but they might have some good input into 
this dialogue.

Regards

Carl

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, February 13, 2007 1:48 PM
Subject: RE: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00 
(PIDF-LOdigitalsignatures)

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 13 Feb 2007 21:04:10 -0500

I believe there are solutions which allow a digital signature to be used
with all of the relevant protocols, albeit with some extension to existing
specifications.  I think that would be preferable to a solution that only
worked with some of them.  The key to doing this is to recognize that even
those protocols that do not use precisely a PIDF LO can have the information
they carry mapped to the fields of a PIDF LO.  We therefore would define a
construction rule for each of the protocols which would yield the same
string in any of the protocols for the same location, compute the hash of
that string and a time stamp, sign that.  Then, no matter what protocol was
used subsequently, a recipient could apply the appropriate rule for the
protocol it used, create the same string, and verify the signature.

The extension would be to specify the rule, and to provide the fields to
pass the signature (and time stamp if needed).

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Tuesday, February 13, 2007 6:48 PM
> To: Brian Rosen; Henning Schulzrinne
> Cc: [email-masked]
> I agree with Brian's assessment here - largely it's about being able to
> eliminate the ability to routinely *and without exploit* misrepresent your
> location. Although Henning does highlight how the use of signatures does
> raise the bar as far as how geographically targeted the exploit has to be.
> 
> I cannot agree that the lack of support of this by "non-L7" protocols
> obviates the ability to have the requirement. It feels like arguing that
> the legacy must always limit the possible. Certainly the NENA requirements
> for the acquisition protocol include the ability to do the things that the
> below-referenced draft mention (that's pretty much the main reason the
> draft was written).
> 
> Cheers,
> Martin
>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 13 Feb 2007 21:10:00 -0500

FYI...

http://tools.ietf.org/wg/geopriv/draft-barnes-geopriv-secure-location- 
object-00.txt

On Feb 13, 2007, at 9:04 PM, Brian Rosen wrote:

>> The threat is the first one.  Script kiddie writes a script that  
>> gets a
>> call
>>> (PIDF-
>>>>> (PIDF-
>> --------------------------------------------------------------------- 
>> -----
>> ----------------------
>> --------------------------------------------------------------------- 
>> -----
>> ----------------------
>> [mf2]
>
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Feb 2007 00:11:36 -0600

I certainly don't mind which solution is used. The NENA requirement for "location dependability" includes elements of authentication and integrity. 

The required characteristics are:
1. Mechanism to identify the source of the location is available
2. Mechanism to detect tampering post-source is available
3. Mechanism to determine the time at which the location information was acquired.
4. Mechanism to distinguish the location object provided by one apparent caller from that of another apparent caller is available.

The Thomson draft was written with these goals in mind. If we can discuss, modify, extend, select from the available specification options that would be fine.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 14 February 2007 1:04 PM
To: Dawson, Martin; 'Henning Schulzrinne'
Cc: [email-masked]
Subject: RE: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00 (PIDF-LOdigitalsignatures)

Brian

---

From: <[email-masked]>
Date: Wed, 14 Feb 2007 14:00:59 -0500

I agree with Brian and Martin. As an emergency services provider, we need a way to do the following things, in order of priority (which may also happen to roughly be in order of feasibility) :

1. prevent a caller to forge his location information from scratch
2. prevent a caller to reuse one of his old valid location
3. prevent a caller to use the currently valid location of someone else (done either by explicit relationship or by network sniffing)
4. prevent an attacker to modify the location of a legitimate caller

We're definitely after prank callers... and the more we catch the better !

I think the need for digital signatures has become apparent, even though the yet-to-be-defined mechanism might not cover the full threat spectrum. In that perspective, the following extract from draft-ietf-geopriv-l7-lcp-ps-00 should be re-addressed :

	10.3.  Requirements
	
	   The following requirements are placed on the location-by-value
	   approach:
	
	   o  No conclusion was reached whether a PIDF-LO or just location
	      information has to be signed.
	
	   o  No conclusion was reached whether location information should be
	      signed.
	
	   o  No conclusion was reached what could be signed.

Regards,

Jérôme

-----Message d'origine-----
De : Dawson, Martin [mailto:[email-masked]] 
Envoyé : 14 février 2007 01:12
À : Brian Rosen; Henning Schulzrinne
Cc : [email-masked]
Objet : RE: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 14 February 2007 1:04 PM
To: Dawson, Martin; 'Henning Schulzrinne'
Cc: [email-masked]
Subject: RE: [Geopriv] WGLC on draft-ietf-geopriv-l7-lcp-ps-00 (PIDF-LOdigitalsignatures)

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 Feb 2007 15:42:34 -0500

Unfortunately, nobody has presented a solution to problem 3, first  
part. In other words, it is very hard to prevent evil Trudy from  
giving her valid location to her co-conspirator Eve. The other  
problems all have reasonably straightforward solutions (time-stamped  
digitally signed LO), assuming the recipient can validate the  
signature (which is the easy part) and can trust the generator of the  
signature (which is a big assumption, which certainly isn't true for  
today's certification infrastructure; fishers can get nice pad-locked  
web sites, too).

On Feb 14, 2007, at 2:00 PM, <[email-masked]> wrote:

> I agree with Brian and Martin. As an emergency services provider,  
> we need a way to do the following things, in order of priority  
> (which may also happen to roughly be in order of feasibility) :
>
> 3. prevent a caller to use the currently valid location of someone  
> else (done either by explicit relationship or by network sniffing)
> I think the need for digital signatures has become apparent, even  
> though the yet-to-be-defined mechanism might not cover the full  
> threat spectrum. In that perspective, the following extract from  
> draft-ietf-geopriv-l7-lcp-ps-00 should be re-addressed :
>
> 	10.3.  Requirements
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Feb 2007 15:27:20 -0600

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 Feb 2007 16:37:22 -0500

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 columbia.edu" 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

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Feb 2007 15:43:47 -0600

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 [mailto:[email-masked]] 
Sent: Thursday, 15 February 2007 8:37 AM
To: Dawson, Martin
Cc: [email-masked]; [email-masked]
Subject: Re: [Geopriv] WGLC
ondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 Feb 2007 23:20:54 -0500

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.

Brian

> Sent: Wednesday, February 14, 2007 4:44 PM
> To: Henning Schulzrinne
> Cc: [email-masked]
> Subject: RE: [Geopriv] WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-
> LOdigitalsignatures)
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 14 Feb 2007 22:33:30 -0600

I'm pleased.  It seems that we are making progress towards a solution.

I have been working for a while on a draft that outlines, in more detail, the "why" and "how" of applying digital signatures to location objects.  It is based largely on section 8 of l7-lcp-ps rather than my old draft.  After a few weeks, it's largely complete - it just needs the trimmings: schema, examples, IANA, some final touches, reorganization and a harsh edit.  I'll publish before the -00 deadline as a discussion piece.

Regards,
Martin

> Sent: Thursday, 15 February 2007 3:21 PM
> Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-
> LOdigitalsignatures)
> 
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > [mf2]
> >
> >

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 Feb 2007 23:37:18 -0500

As long as it works with L7 LCP, DHCP and LLDP-MED and maybe SUPL, great.

Brian

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Wednesday, February 14, 2007 11:34 PM
> To: Brian Rosen; Dawson, Martin; Henning Schulzrinne
> Cc: [email-masked]
> I have been working for a while on a draft that outlines, in more detail,
> the "why" and "how" of applying digital signatures to location objects.
> It is based largely on section 8 of l7-lcp-ps rather than my old draft.
> After a few weeks, it's largely complete - it just needs the trimmings:
> schema, examples, IANA, some final touches, reorganization and a harsh
> edit.  I'll publish before the -00 deadline as a discussion piece.
> 
> Regards,
> Martin
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 14 Feb 2007 23:22:36 -0600

I'm sorry.  I seem to have misplaced my magic wand.

I can recommend a solution for DHCP - since a new option is required to carry the signature, let's just make that option carry a PIDF-LO.  It's less fussy that way and we avoid any concerns about the format.

As for the others, they aren't IETF protocols, but I'm sure it wont be too hard to convince the other SDOs to change:

LLDP-MED already has an option to carry a PIDF-LO, so no problem there.  Just deprecate the RFC3825 format.

SUPL uses 3GPP GAD, so you'd be better off talking to 3GPP.  Perhaps we can also come to some arrangement with 3GPP so that we can squeeze a signature into a few protocols.  After all 23.271 specifies mobile-originated location requests.  That's a minor change to... (lemme see)... MAP, RRC, RRLP, BSSMAP-LE, and PCAP spring to mind.

As for SUPL - you probably want to get MLP as well, but that's XML so maybe there is something we can do (I'll let you talk OMA into changing).

Oh yeah, and OMA want to include civic addresses - we can give them those for free while we're at it.

Enjoy,
Martin

> Sent: Thursday, 15 February 2007 3:37 PM
> To: Thomson, Martin; Dawson, Martin; 'Henning Schulzrinne'
> Cc: [email-masked]
> > > > --------------------------------------------------------------------
> --
> > --
> > > --
> > > > ----------------------
> > > > --------------------------------------------------------------------
> --
> > --
> > > --
> > > > ----------------------
> > > > [mf2]
> > > >
> > > >

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 Feb 2007 23:37:28 -0600

Yes - the intent of the requirement, and the draft, is that a mechanism
is provided to sign a PIDF-LO in a way that supports the integrity
characteristics we have discussed. This is specific to PIDF-LO and
independent of the acquisition protocol.

The signature is only useful in conjunction with the location object and
the form of the location information will dictate which signature form
is used. This draft does not preclude the existence of another spec
defining a way to generate a signature, meeting the same requirements,
for some other location form.

The responsibility for acquisition protocols, then, is to ensure that
there is an appropriate signature definition for their form of location
encoding (this draft covers those that use PIDF-LO so those protocols
are now covered) and that there is a way to explicitly or otherwise get
the LIS to provide the signature when it is needed. These issues are up
to the location acquisition protocols to deal with - but it's not a
constraint that should be put on the PIDF-LO signature spec.

Cheers,
Martin

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Thursday, 15 February 2007 4:23 PM
To: Brian Rosen
Cc: [email-masked]
Subject: RE:
[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

I can recommend a solution for DHCP - since a new option is required to
carry the signature, let's just make that option carry a PIDF-LO.  It's
less fussy that way and we avoid any concerns about the format.

As for the others, they aren't IETF protocols, but I'm sure it wont be
too hard to convince the other SDOs to change:

LLDP-MED already has an option to carry a PIDF-LO, so no problem there.
Just deprecate the RFC3825 format.

SUPL uses 3GPP GAD, so you'd be better off talking to 3GPP.  Perhaps we
can also come to some arrangement with 3GPP so that we can squeeze a
signature into a few protocols.  After all 23.271 specifies
mobile-originated location requests.  That's a minor change to... (lemme
see)... MAP, RRC, RRLP, BSSMAP-LE, and PCAP spring to mind.

As for SUPL - you probably want to get MLP as well, but that's XML so
maybe there is something we can do (I'll let you talk OMA into
changing).

Oh yeah, and OMA want to include civic addresses - we can give them
those for free while we're at it.

Enjoy,
Martin

> > > 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
> > > 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
> > > > 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
> > > > I actually just think of the identity as a unique random number
that
> > the
> > > > precisely by "access network identify", but this doesn't have to
be
> a
> > > > > So - the important thing is for the PIDF-LO to be associated
with
> a

------------------------
------------------------

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 15 Feb 2007 11:04:21 -0500

I really don't know what to do about the OMA protocols; it's a big problem.

We can probably work with TIA and we certainly can work with the DHCP stuff
to agree on a signature mechanism.  I would prefer you approach this in a
spirit other than "I've solved the problem for PIDF-LO, the rest of you can
just change to make my solution work with your protocol".

Nevertheless, we might want to ask, with a couple of years of further work
on location protocols behind us, if in fact allowing a PIDF-LO through DHCP
is a good idea.

John S/Marc: if you were starting today, what would you say?

Brian

> Sent: Thursday, February 15, 2007 12:23 AM
> To: Brian Rosen
> Cc: [email-masked]
> As for the others, they aren't IETF protocols, but I'm sure it wont be too
> hard to convince the other SDOs to change:
> 
> signature into a few protocols.  After all 23.271 specifies mobile-
> originated location requests.  That's a minor change to... (lemme see)...
> MAP, RRC, RRLP, BSSMAP-LE, and PCAP spring to mind.
> 
> maybe there is something we can do (I'll let you talk OMA into changing).
> 
> > > > Enterprise is a little more difficult, just because of the numbers.
> I
> > > > think

---

From: John Schnizlein <[email-masked]>
Date: Thu, 15 Feb 2007 14:46:34 -0800

> John S/Marc: if you were starting today, what would you say?

Starting today, because network infrastructure is still more
stationary than hosts that attach to it, the network operator
can use the Internet standard mechanism for configuring the
location of the point where a host attaches.  Location is
local information, and dynamic host configuration protocol
(DHCP) is appropriate for local information.  DHCP clients
can request just those configuration options they want, and
are free to ignore any option.  The model is that hosts make
the local information available to, or use it to support
applications on the host.

Because of the variable components of civil addresses, and
the universality of geographic coordinates, we still think
that coordinates are ideal, while civil locations may be used
for some time.  Since every position in the real world has
some limited precision, and fixed-length binary is more
efficient for a small and quick protocol like DHCP, coding
the resolution of each coordinate as significant (binary)
digits is appropriate.  Summary: the parameters of the
geographic location option still look good.

w.r.t. signing:

Much hype surrounding the utilization of digital signing has been put  
forth.
A fear is that current expectation is far greater than capability.

What will be the operational differences for emergency response when  
they
receive:

1) A location object signed by a verifiable entity.
2) A location object signed by an unverifiable entity.
3) A location with no signature.

It is accepted that emergency calling is a very small (<1%)  
application for
the use of location information.

Given the above, is the amount of work to perform digital signatures  
worth
the effort?

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 15 Feb 2007 16:53:36 -0600

> they receive:

This will be up to the emergency providers and corresponding
jurisdiction regulators. Without the signature mechanism, they would
have no basis on which to implement a policy.

> It is accepted that emergency calling is a very small (<1%)
application
>  for the use of location information.

> worth the effort?

Most certainly, yes.

Cheers,
Martin

-----Original Message-----
From: John Schnizlein [mailto:[email-masked]] 
Sent: Friday, 16 February 2007 9:47 AM
To: Brian Rosen
Cc: [email-masked]; Thomson, Martin
Subject: Re:

w.r.t. signing:

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 15 Feb 2007 17:55:59 -0600

While my email was flippant (and I couldn't pretend otherwise), you need to realize that what you ask is a big task.

I believe that the correct approach is to address the GEOPRIV-defined location object, the PIDF-LO.  This addresses that class of protocols known as GEOPRIV using-protocols.

If I was starting today, I would have trouble finding a reason to use anything other than PIDF-LO.

> Sent: Friday, 16 February 2007 3:04 AM
> To: Thomson, Martin
> Cc: [email-masked]
> too
> numbers.
> > > > > > NAS identity, say. It could just as well be a (public) IP
> address
> > or
> > > > > > > identity. Note that this "identity" is the anonymous
> appearance
> > of
> > > > > > ----------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > > ----------------------
> > > > > > ----------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > > ----------------------
> > > > > > [mf2]
> > > > > >
> > > > > >

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 15 Feb 2007 19:26:57 -0600

I'd also add that I don't think the OMA protocols (or the 3GPP) ones,
for that matter, are a big problem.

You have to understand the context in which they are used - which is
well-established cellular networks and their associated location
services infrastructure. The cellular industry has been doing location
determination, acquisition, and conveyance for years and they've
invested mightily in it. Clearly they are not going to fall about the
place and modify all their existing architectures, protocols, and
implementations just because the IETF now has something to say on the
topic.

This does not become a problem as long as that entire existing
infrastructure is used within the walled garden of the cellular context
- with the associated tight coupling between the access operators, their
access roaming partners, and the voice and other cellular location
service providers.

It only becomes a problem once these networks bump up against the
Internet. For example, the subscriber just wants to use the cellular
network for broadband wireless Internet access but, perhaps, uses Skype.
In this case, the client would like to treat it like any other Internet
access network - discover a LIS, get a PIDF-LO and away it goes. Going
specifically into control-plane mobile originated location request mode
via a UMTS RNC and then converting the WGS-84 shape returned into a
PIDF-LO before using it with the generic Internet application (Skype)
doesn't quite achieve the desired level of transparency.

The solution for cellular broadband providers, if they want to be
regarded as equal to the majority of other Internet access providers, is
to provide a LIS in their access. Unlike DSL and the other providers,
these operators don't have to start from scratch. They already have a
huge start in terms of implemented location infrastructure. All they
have to do is invoke that legacy from their LIS. The LIS will invoke
SUPL and/or control-plane location. The established protocols such as
MLP, MAP, BSSAP-LE, IS-801, RRLP, ULP (SUPL), and PCAP will come into
play. The LIS provides the bridge between the Internet model and the
legacy cellular model. It does the conversion between location
presentation forms; it supports things such as signing, assertion, and
location reference management. It just doesn't need to implement any new
location generation functions because it rides on what already exists.

The industry can only start from where it is; trying to wind the clock
back to the year dot and have everyone start again is not a practical
way forward.

Cheers,
Martin

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Friday, 16 February 2007 10:56 AM
To: Brian Rosen
Cc: [email-masked]
Subject: RE:

While my email was flippant (and I couldn't pretend otherwise), you need
to realize that what you ask is a big task.

I believe that the correct approach is to address the GEOPRIV-defined
location object, the PIDF-LO.  This addresses that class of protocols
known as GEOPRIV using-protocols.

If I was starting today, I would have trouble finding a reason to use
anything other than PIDF-LO.

> spirit other than "I've solved the problem for PIDF-LO, the rest of
you
> can
[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-
> > > > I have been working for a while on a draft that outlines, in
more
> > > detail,
[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-
> > > > > We actually think we can have a real PKI for PSAPs, but just
doing
> > > local
> > > > > > LIS generates. That, coupled, with the LIS identity makes
for a
> > > > globally
> > > > > > unique identity that the location recipient can be
comfortable
> > > > > > 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
> > > > > > "socket 17 at columbia.edu" or "AP 42 at the Anytown
Starbucks",
> > > even
> > > > > > if they all have different MAC addresses, something is
likely
> > fishy.
> > > > > > > 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
> > > > > > >> presumably, bogus one but they are not particularly
concerned
> > as
> > > > > > >> to whether it is Eve that is effectively dialling them
rather
> > > than
> > > > > > > policy can be applied against getting two calls arriving
with
> > this
> > > > > > > subscriber identity. The latter is not the access
network's
> job.
> > > > > > > Requirement 3 is about providing a mechanism for the
access
> > > network

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 15 Feb 2007 23:16:03 -0500

The actual question I had in mind was, would a PIDF-LO make sense through
DHCP rather than the DHCP specific format we presently use?  The problem, I
expect, if there is one, might be the size of the PIDF.

WRT signatures, the PSAP will treat locations with a good signature
differently than one without a signature or with a bad signature.  It will
question the caller more closely.  It will alert the responders that there
is a possibility that the location is not accurate.  

When it is under attack, it may answer calls with a good signature before it
answers calls with a missing or bad signature.

Pizza Hut has the same problems as the PSAP.  It may be more likely to not
deliver if it gets a missing or bad signature.

Brian

> Sent: Thursday, February 15, 2007 5:47 PM
> To: Brian Rosen
> Cc: 'Thomson, Martin'; [email-masked]
> Subject: Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-
> LOdigitalsignatures)
>

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 16 Feb 2007 20:18:59 -0500

Brian,

> 
> WRT signatures, the PSAP will treat locations with a good 
> signature differently than one without a signature or with a 
> bad signature.  It will question the caller more closely.  It 
> will alert the responders that there is a possibility that 
> the location is not accurate.  
> 
> When it is under attack, it may answer calls with a good 
> signature before it answers calls with a missing or bad signature.
> 
> Pizza Hut has the same problems as the PSAP.  It may be more 
> likely to not deliver if it gets a missing or bad signature.

I certainly hope you understand that signatures simply move the attack
vector.  What you are stating is signed/verified location objects will be
trusted at a higher status than signed/unverifiable or unsigned.  The attack
vector is now the level of trust.  

If the PSAP simply trusts good signatures, a smart attack would include a
barrage of calls with the varying forms of location objects, and of course,
the most trusted one will now be the exact location the attacker wants to
send the responders.  This isn't rocket science!

You know this can be accomplished, albeit, it takes a slightly smarter
attacker, of which there are many.

I believe a safer solution would be for the PSAP to not trust any location,
THE SAME WAY THEY DO TODAY.  Besides, a signed verified location object is
ALWAYS overridden by the human on the bearer channel.

Signing location objects opens an additional attack vector fooling the PSAP
with (false) trust!  And a lot of work to open this avenue for attack!

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 19 Feb 2007 00:12:36 -0600

So how, without exploit, does the attacker launch an arbitrary number of
calls with signed location objects that appear to come from discrete
devices at a specific location at a specific point in time?

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Saturday, 17 February 2007 12:19 PM
To: 'Brian Rosen'
Cc: [email-masked]
Subject: RE:

Brian,

I certainly hope you understand that signatures simply move the attack
vector.  What you are stating is signed/verified location objects will
be
trusted at a higher status than signed/unverifiable or unsigned.  The
attack
vector is now the level of trust.  

If the PSAP simply trusts good signatures, a smart attack would include
a
barrage of calls with the varying forms of location objects, and of
course,
the most trusted one will now be the exact location the attacker wants
to
send the responders.  This isn't rocket science!

I believe a safer solution would be for the PSAP to not trust any
location,
THE SAME WAY THEY DO TODAY.  Besides, a signed verified location object
is
ALWAYS overridden by the human on the bearer channel.

Signing location objects opens an additional attack vector fooling the
PSAP
with (false) trust!  And a lot of work to open this avenue for attack!

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Feb 2007 08:18:33 -0500

Bot nets are currently by far the most common attack vector for DOS  
attacks and spam; they are rumored to be up to hundreds of thousands  
of hosts strong, and available for rent. An attacker that would want  
to disrupt PSAP operations (as opposed to the usual lone prank  
caller) would need a bot net in any event since otherwise it is too  
easy, from an attacker's point of view, to filter a few attack hosts  
by just noting that all calls are coming from the same IP address.

As I noted before, we need to be really clear as to whether we're  
protecting against individual human prank callers or a coordinated  
bot attack. For the prank caller, an open WiFi network is probably  
the rough equivalent of today's pay phone as a tool of choice. As  
long as everyone understands that signed location information doesn't  
help with these payphone-like attacks, we can discuss the merits of  
signing.

http://en.wikipedia.org/wiki/Botnet has details with sources:

"The Dutch police found a 1.5 million node botnet[1] and the  
Norwegian ISP Telenor disbanded a 10,000 node botnet.[2] Large  
coordinated international efforts to shutdown botnets have also been  
initiated.[3] It has been estimated that up to one quarter of all  
personal computers connected to the internet are part of a botnet.[4]"

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 19 Feb 2007 21:17:00 -0600

That didn't meet the specification of being done "without exploit". We
can't address the general problem of the security holes currently in the
Internet.

The existence of bot nets is a generic Internet problem and the issues
go well beyond the domain of location integrity. It has to be addressed
- but it should not preclude the existence of integrity mechanisms
within the location domain.

Cheers,
Martin

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Feb 2007 22:35:00 -0500

One could mention the old joke about searching for lost keys near the  
light.

This makes no sense - bot nets are currently the most widely used  
mechanism for doing network damage of all kinds. Assuming that we  
have the threat model of 1980 doesn't exactly help.

I have not argued that this precludes the use of signatures, just  
that the impact on large-scale attacks is likely to be close to zero.  
(Large-scale attacks are actually likely to be made worse, since  
verifying signatures takes effort, i.e., provides in itself a DOS  
target.) We just need to be honest about the very limited range of  
attacks that this mechanism prevents, to avoid adding to the supply  
of security snake oil.

Without strong identity assertion, even the single-human attack is  
not likely to be prevented by location signatures, as long as we  
don't disallow open wireless networks.

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 19 Feb 2007 21:47:09 -0600

In the absence of any proof one way or the other about how realistic a
managed bot net attack is in this space, I'm fine with leaving it as an
academic discussion. I'm satisfied that it is still a scenario that
requires the same level of discrete device presence in the PSAP
catchment as if the calls were made by people. I could imagine the same
thing being done with a mobile phone virus or the classic magic modem
dialer attack for the PSTN. The bar has been raised to the equivalent
level.

The important thing is that we all agree that it's worth proceeding with
the mechanism.

One thing that is interesting - if the bot net "operators" are happy to
let you use their facility for this purpose, then it would actually be
possible to utilise their network to find out the location of the
individual elements of the network. Ironically, this would allow a law
enforcement organization to hire the bot net service and have the
devices report their location directly to the authority, complete with
signed/verifiable content. That would have to be useful intelligence.
Nice one.

Cheers,
Martin

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 20 Feb 2007 17:39:58 -0500

Bot nets can generate good location data, with valid signatures.  Each of
the zombies could get off one valid call before being detected.  What
signatures could do is prevent totally spoofed locations.  We MIGHT be able
to detect the call as at least suspect some time after the attack starts,
and reduce the effectiveness to considerably less than one per zombie.
Generally speaking, I think we're mostly trying to stop prank calls, and we
won't be 100% effective at that, but we would be effective enough to make
the effort worthwhile.

Brian

> Sent: Monday, February 19, 2007 10:35 PM
> To: Dawson, Martin
> Cc: GEOPRIV

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 22 Feb 2007 10:52:54 -0500

Brian,

1) One problem is that PSAPs will response to un-signed locations, they have
no choice.  IP hosts will deploy self location determination/user input and
send the results un-signed to PSAPs.  If you accept this as fact, you cannot
eliminate totally spoofed locations.  Additionally, as you admit, it is
possible to defeat digital signatures.

2) I have not heard PSAPs admit/accept the negative to the solution, digital
signatures opens up the new attack vector.  Digital signatures do nothing
more that add 'machinery' to the equation, spoofing the 'human' element.  If
this 'machinery' is capable of presenting a new problem, the 'human' who
will be subject to this new problem must admit/accept the additional
workload.  

The problem I see is, once again, the expectations of the solution are not
even close to the capabilities, yet we forge ahead believing we are solving
world hunger.  Like Henning, I've not argued that signatures are totally
useless, only arguing they won't meet current expectations, hence not enough
ROI.

-Marc-

> Sent: Tuesday, February 20, 2007 5:40 PM
> To: 'Henning Schulzrinne'; 'Dawson, Martin'
> Cc: 'GEOPRIV'
> Subject: RE: 
> Bot nets can generate good location data, with valid 
> signatures.  Each of the zombies could get off one valid call 
> before being detected.  What signatures could do is prevent 
> totally spoofed locations.  We MIGHT be able to detect the 
> call as at least suspect some time after the attack starts, 
> Generally speaking, I think we're mostly trying to stop prank 
> calls, and we won't be 100% effective at that, but we would 
> be effective enough to make the effort worthwhile.
> 
> Brian
> 
> > mechanism for doing network damage of all kinds. Assuming 
> that we have 
> > the threat model of 1980 doesn't exactly help.
> > 
> > I have not argued that this precludes the use of 
> signatures, just that 
> > the impact on large-scale attacks is likely to be close to zero.
> > attacks that this mechanism prevents, to avoid adding to 
> the supply of 
> > security snake oil.
> > 
> > Without strong identity assertion, even the single-human 
> attack is not 
> > likely to be prevented by location signatures, as long as we don't 
> > disallow open wireless networks.
> > 
> > > That didn't meet the specification of being done "without 
> exploit". 
> > > We can't address the general problem of the security 
> holes currently 
> > > in the Internet.
> > >
> > > The existence of bot nets is a generic Internet problem and the 
> > > issues go well beyond the domain of location integrity. 
> It has to be 
> > > addressed

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 26 Feb 2007 18:16:09 -0600

And just so long as people appreciate that not everyone agrees with this
assessment...

Properly applied signature security means that each call needs to come
from a corresponding physical presence in the area of coverage of the
PSAP. The only description of an attack that I have seen is using a "bot
net" or other set of compromised devices that can be established in the
target area and used to launch the attack. It is a matter of judgement
as to whether this represents a significant additional hurdle compared
to being able to routinely and effectively spoof your location from any
position on the Earth and without having to compromise any machines. I
think that is a significant improvement. I believe that if we didn't
introduce the location integrity mechanism now, we would need to add it
at some point in the near future at which point the cost of doing so
will be considerably higher.

If bot nets are the convenient source of compromised machines - then a
federal law enforcement agency would be able to hire that same net to
mount a DOS on their own honey-pot service. Then all their service has
to do is collect the signed and source-verifiable locations associated
with each call. This will immediately give them a very useful map of the
accurate locations of compromised machines in the jurisdiction that they
control. Either this mechanism will actually contribute to the overall
security of the Internet or bot net operators will have to find a way to
prevent their zombie machines from sending this location information. In
the latter case, it obviates the ability to use them for the particular
attack we are discussing.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Friday, 23 February 2007 2:53 AM
To: 'Brian Rosen'
Cc: 'GEOPRIV'
Subject: RE:

Brian,

1) One problem is that PSAPs will response to un-signed locations, they
have
no choice.  IP hosts will deploy self location determination/user input
and
send the results un-signed to PSAPs.  If you accept this as fact, you
cannot
eliminate totally spoofed locations.  Additionally, as you admit, it is
possible to defeat digital signatures.

2) I have not heard PSAPs admit/accept the negative to the solution,
digital
signatures opens up the new attack vector.  Digital signatures do
nothing
more that add 'machinery' to the equation, spoofing the 'human' element.
If
this 'machinery' is capable of presenting a new problem, the 'human' who
will be subject to this new problem must admit/accept the additional
workload.  

The problem I see is, once again, the expectations of the solution are
not
even close to the capabilities, yet we forge ahead believing we are
solving
world hunger.  Like Henning, I've not argued that signatures are totally
useless, only arguing they won't meet current expectations, hence not
enough
ROI.

-Marc-

---

From: Andrew Newton <[email-masked]>
Date: Mon, 26 Feb 2007 20:43:19 -0500

On Feb 26, 2007, at 7:16 PM, Dawson, Martin wrote:

> I believe that if we didn't

Given that ALIs, etc... are all spoofable on the PSTN today and we  
see not real outcry about it, musing that it will cost us more to add  
security we know we will need later is speculative, especially when  
the security we spec today based on what we think we need maybe too  
burdensome, insecure, or both.

> mount a DOS on their own honey-pot service.

Which mythical federal law enforcement agency are you referencing?

-andy

---

From: <[email-masked]>
Date: Mon, 26 Feb 2007 21:50:02 -0500

Andy,

< Given that ALIs, etc... are all spoofable on the PSTN today and we  
see not real outcry about it>

When E9-1-1 was first introduced, there was no way at that time that the ANI could be spoofed. It has been engineered to be secured. Technology evolution on the PSTN created some "security holes" and the Emergency Services community is quite concern about those.

While I can't speak on the cost of doing it now or later, I can see the value of trying to make the information secure at the onset.

What I've read so far on this issue is that there was some kind of general agreement on the value for signed LOs until the following caveat were brought to light:

1) Does not cover bot net attacks;
2) May create a false sense of trust at a PSAP (changing the threat vector).

For 1), it was mentioned this was a generalized threat to the Internet. It may not be for this solution to solve it then.

For 2), in the case where the signed LO (SLO) is passed to the PSAP, it should not preclude the call taker to confirm the address with the caller. This is normal procedures. Actually, a signed LO should not create a higher sense of trust as with a call from the PSTN today, but the lack of signature on the LO should raise suspicion and direct the call taker to take special care with that call.

Guy Caron
-----Message d'origine-----
De : Andrew Newton [mailto:[email-masked]] 
Envoyé : 26 février 2007 20:43
À : Dawson, Martin
Cc : GEOPRIV; Marc Linsner
Objet : Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

-andy

---

From: Andrew Newton <[email-masked]>
Date: Mon, 26 Feb 2007 22:04:19 -0500

On Feb 26, 2007, at 9:50 PM, [email-masked] wrote:

> When E9-1-1 was first introduced, there was no way at that time  
> that the ANI could be spoofed. It has been engineered to be  
> secured. Technology evolution on the PSTN created some "security  
> holes" and the Emergency Services community is quite concern about  
> those.

 From what I can tell, ANIs where originally created for billing  
purposes and only later repurposed for 9-1-1.  They've never been  
secure.

But my original statement was, there is no big outcry to fix the  
security hole in the PSTN.  Sure it is a known problem.

> For 1), it was mentioned this was a generalized threat to the  
> Internet. It may not be for this solution to solve it then.

Let's be clear, crypto provides its own new attack vector.  It isn't  
just that you have to worry about the standard class of threats faced  
my an email server or blog provider.

> For 2), in the case where the signed LO (SLO) is passed to the  
> PSAP, it should not preclude the call taker to confirm the address  
> with the caller. This is normal procedures. Actually, a signed LO  
> should not create a higher sense of trust as with a call from the  
> PSTN today, but the lack of signature on the LO should raise  
> suspicion and direct the call taker to take special care with that  
> call.

What, exactly, does the PSAP do differently with no signature or an  
invalid signature?

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 26 Feb 2007 21:10:21 -0600

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Tuesday, 27 February 2007 12:43 PM
To: Dawson, Martin
Cc: Marc Linsner; Brian Rosen; GEOPRIV
Subject: Re:

[[MCD]] Sorry? My company provides a GMLC product, and we do have
measures in place to authenticate/authorize the ALI before location
requests are permitted from it. Our customers require this. Your
argument, then, is that they simply shouldn't bother and let any
Internet based host query the GMLC for location? The use case, of
course, is quite different but I guess that never stopped a good piece
of rhetoric. As a matter of general principle, it is more cost-effective
to include mechanisms when initially deploying a system rather than
trying to retrofit them later. Maybe it's speculation, but it's
certainly not unreasonable. 

Which mythical federal law enforcement agency are you referencing?
[[MCD]] Nice. I think the correct word would be "hypothetical". The
operators of bot-nets have their own economies - they have to have
customers to feed their business, so why couldn't a law enforcement
agency become a customer? A DOS from a set of zombie machines that
provided certified location information would thus be providing their
precise location. Is there something untrue about that?

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 26 Feb 2007 21:12:42 -0600

What security hole? Please spell out exactly how you feel that ALIs
(which is different to ANI anyway - no pun intended)are insecure? And,
in any case, how has that got anything to do with how easy it is for an
emergency caller from another country to appear to be calling from the
PSAP catchment?

Martin

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Tuesday, 27 February 2007 2:04 PM
To: [email-masked]
Cc: Dawson, Martin; [email-masked]; [email-masked]
Subject: Re:

-andy

---

From: <[email-masked]>
Date: Mon, 26 Feb 2007 22:17:24 -0500

Andrew,

< What, exactly, does the PSAP do differently with no signature or an  
invalid signature? >

Well, I can only speculate as, to my knowledge, this is not a current situation. However, it could be foreseen that, as an example, a call taker would try to cross validate the information by say, asking the caller sub information to corroborate the provided information. But don't get hooked on the example only. The point is that it just raises awareness that something may be wrong with that call. 

Guy Caron
-----Message d'origine-----
De : Andrew Newton [mailto:[email-masked]] 
Envoyé : 26 février 2007 22:04
À : Caron, Guy (A162859)
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 26 Feb 2007 23:19:51 -0500

Martin, 

In-line...

> 
> Properly applied signature security means that each call 
> needs to come from a corresponding physical presence in the 
> area of coverage of the PSAP.

This statement is incorrect.  A LO, signed or not, is a stand alone piece of
data that can be launched from *anywhere*.

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 26 Feb 2007 22:23:21 -0600

The scenario I can imagine is pertinent to the DOS situation. People are bandying the term "attack vector" around; well the attack vector under discussion is where multiple devices are used to call a single PSAP, reporting their location in that PSAP catchment, when they are not actually there. This sort of attack is not the same as a DOS attack on a server. The resources are human, their numbers are limited, and the time to detect is quite protracted.

The argument that PSAPs have to answer the call anyway is not valid in the situation where they can't answer all the calls. When the PSAP becomes overloaded, and especially where there is an unexpected spike in calls with unsigned locations, then it's quite reasonable to apply a policy that says that calls with signed location will be given priority until the excessive call volume abates. Without the signed location mechanism there would be nothing to base that policy on.

I certainly echo Guy's sentiment though. We don't have to anticipate the exact details of the policy that the PSAP applies; they are the ones that have the right and responsibility to work that out. We are just giving them another criterion for their policies to work from.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, 27 February 2007 2:17 PM
To: [email-masked]
Cc: Dawson, Martin; [email-masked]; [email-masked]
Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

Andrew,

Guy Caron
-----Message d'origine-----

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 26 Feb 2007 22:33:44 -0600

Marc - either you have not read all the threads that outline what pieces
of information the signature validates or you are deliberately ignoring
the point that your scenario still requires a concurrent presence in the
area of coverage. 

The signature, as described in the draft under discussion, includes the
location, the time of applicability, and the unique identity assigned by
the LIS to the client. The LO cannot be stored and replayed later
because now the time is invaled and multiple calls using the same LO
present a signature suggesting it is being used by more than one device.

The LO cannot be sent from somewhere else in the world unless it is
obtained from the area of coverage by a corresponding device at the same
time that the call is made. Now we're back to bot nets or whatever
providing that physical presence necessary to obtain the currently
applicable LO.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Tuesday, 27 February 2007 3:20 PM
To: Dawson, Martin
Cc: 'GEOPRIV'
Subject: RE:

Martin, 

In-line...

> area of coverage of the PSAP.

This statement is incorrect.  A LO, signed or not, is a stand alone
piece of
data that can be launched from *anywhere*.

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 27 Feb 2007 08:00:36 -0500

Marc

One of the security tenants we live with is that nearly all security
mechanisms can be breached if the attacker is skilled enough, or spends
enough money.  The attack I want to prevent is a script kiddie sending cops
on a wild goose chase.  They do this now with pay phones.  With VoIP, we
make it MUCH easier to mount this attack.  I want to get the cost of the
attack high enough that it takes a major organized effort costing
significant sums.

Signatures do that.

It IS possible to spoof ANI today.  It's much easier now than it was even a
couple years ago, which is a problem to the emergency call system.   Until
we "broke" ANI, PSAPs were pretty immune to spoof of location except from
highly organized and well financed groups or very highly skilled hackers.
With IP endpoints, we have lowered the bar to trivial spoof far too low.  We
need to raise it, and signatures will raise it.  We can argue how high the
bar gets raised, but without signatures, pretty much anyone who can program
can cause an emergency call to appear like it comes from anywhere they want
it to.  That bar is too low. 

I'm happy to discuss alternate ways to prevent trivial forgery of location.
I'm not at all happy to drop signatures as a viable way to do that unless
you can show that a trivial attack works in the presence of a signature
requirement.

It is a fact that PSAPs believe what they are told.  Regardless of what the
automatic mechanisms say about location, they go where the caller tells them
to go.  However, they do know how to handle suspicious calls.  They do know
how to back track.  They know how to send back up units.  Suspicion is
something they know how to deal with.

Brian

> Sent: Monday, February 26, 2007 11:20 PM
> To: 'Dawson, Martin'
> Cc: 'GEOPRIV'

---

From: Andrew Newton <[email-masked]>
Date: Tue, 27 Feb 2007 10:42:31 -0500

> emergency caller from another country to appear to be calling from the

Sorry, I meant to say ANI.  But the fact that the ANI is used to get  
the ALI is a security issue.

It is especially telling given that there are companies in foreign  
countries that specialize in faking US ANIs.  They'll take your  
credit card over the web.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 27 Feb 2007 11:09:58 -0500

On Feb 26, 2007, at 10:17 PM, [email-masked] wrote:

> Well, I can only speculate as, to my knowledge, this is not a  
> current situation. However, it could be foreseen that, as an  
> example, a call taker would try to cross validate the information  
> by say, asking the caller sub information to corroborate the  
> provided information. But don't get hooked on the example only. The  
> point is that it just raises awareness that something may be wrong  
> with that call.

Guy,

I'm a little concerned that we are missing some points in this  
discussion.  Thanks for your patience.

It is my understanding that in all cases where a PSAP is able to talk  
to a person on the other end of the phone, that they will trust the  
location given verbally over any automated location regardless of  
crypto bells and whistles.  The location from the network may get  
used if the emergency responders cannot use the information given by  
the caller, but in this case signed location seems of little value.

Where signed location seems to have more validity is in the case  
where the PSAP cannot talk to the caller, such as a 9-1-1 hang-up.   
However, even in this case it wouldn't take more than a few calls an  
hour for the PSAP to catch on to the problem and change tactics.  So  
the question comes down to this, can signed location be enough of a  
differentiation from non-signed or invalidly signed location where a  
PSAP would quit ignoring calls?  Even with signed location, it is  
possible to have a coordinated attack within the window necessary to  
trigger the PSAPs alternate tactics.

-andy

---

From: "Stuard, Doug" <[email-masked]>
Date: Tue, 27 Feb 2007 11:21:34 -0500

Perhaps I'm missing something, but what I haven't seen mentioned is the
routing function.

Specific location information is of course desired to dispatch
resources, and call takers can (and do) have a number of sniff tests to
determine if a  call or displayed location might be bogus, but the call
must first be routed to the correct PSAP.  While of larger granularity
than actual caller location, it would be subject to the various
vulnerabilities discussed, and without benefit of call taker skepticism.

Doug Stuard

________________________________

From: Andrew Newton [mailto:[email-masked]] 
Sent: Tuesday, February 27, 2007 11:10 AM
To: [email-masked]
Cc: [email-masked]; Dawson, Martin; [email-masked]
Subject: Re:
[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

Well, I can only speculate as, to my knowledge, this is not a current
situation. However, it could be foreseen that, as an example, a call
taker would try to cross validate the information by say, asking the
caller sub information to corroborate the provided information. But
don't get hooked on the example only. The point is that it just raises
awareness that something may be wrong with that call. 

Guy,

It is my understanding that in all cases where a PSAP is able to talk to
a person on the other end of the phone, that they will trust the
location given verbally over any automated location regardless of crypto
bells and whistles.  The location from the network may get used if the
emergency responders cannot use the information given by the caller, but
in this case signed location seems of little value.

Where signed location seems to have more validity is in the case where
the PSAP cannot talk to the caller, such as a 9-1-1 hang-up.  However,
even in this case it wouldn't take more than a few calls an hour for the
PSAP to catch on to the problem and change tactics.  So the question
comes down to this, can signed location be enough of a differentiation
from non-signed or invalidly signed location where a PSAP would quit
ignoring calls?  Even with signed location, it is possible to have a
coordinated attack within the window necessary to trigger the PSAPs
alternate tactics.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 27 Feb 2007 11:42:57 -0500

Yes, but you have no choice, under normal circumstances, other than to route
where it tells you to route.  You can't drop a call because it looks
suspicious, and at least at the moment, the PSAPs don't want a designated
sucker which would be some kind of a call center that gets suspicious calls.

When the PSAP is under attack, it may be possible to divert calls earlier in
the routing process that don't have valid signatures (possibly in
combination with other factors) to secondary queues or IVR or something
else.  We're planning on doing that in the U.S. system.

PSAPs deal with suspicious calls now.  They probably will have to get more
adept at dealing with them, because IP networks are more open and they are
likely to happen more often.  That is something we're getting them
comfortable with.  However, they want as much information as we can give
them, and signatures seem like something that is useful.

Brian

  _____  

From: Stuard, Doug [mailto:[email-masked]] 
Sent: Tuesday, February 27, 2007 11:22 AM
To: Andrew Newton; [email-masked]
Cc: [email-masked]; Dawson, Martin; [email-masked]
Subject: RE:
[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

Specific location information is of course desired to dispatch resources,
and call takers can (and do) have a number of sniff tests to determine if a
call or displayed location might be bogus, but the call must first be routed
to the correct PSAP.  While of larger granularity than actual caller
location, it would be subject to the various vulnerabilities discussed, and
without benefit of call taker skepticism.

Doug Stuard

  _____  

 

Well, I can only speculate as, to my knowledge, this is not a current
situation. However, it could be foreseen that, as an example, a call taker
would try to cross validate the information by say, asking the caller sub
information to corroborate the provided information. But don't get hooked on
the example only. The point is that it just raises awareness that something
may be wrong with that call. 

Guy,

I'm a little concerned that we are missing some points in this discussion.
Thanks for your patience.

It is my understanding that in all cases where a PSAP is able to talk to a
person on the other end of the phone, that they will trust the location
given verbally over any automated location regardless of crypto bells and
whistles.  The location from the network may get used if the emergency
responders cannot use the information given by the caller, but in this case
signed location seems of little value.

Where signed location seems to have more validity is in the case where the
PSAP cannot talk to the caller, such as a 9-1-1 hang-up.  However, even in
this case it wouldn't take more than a few calls an hour for the PSAP to
catch on to the problem and change tactics.  So the question comes down to
this, can signed location be enough of a differentiation from non-signed or
invalidly signed location where a PSAP would quit ignoring calls?  Even with
signed location, it is possible to have a coordinated attack within the
window necessary to trigger the PSAPs alternate tactics.

-andy

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 27 Feb 2007 15:47:08 -0600

In order to spoof an ANI on the PSTN, something like the following is
required

* You have to acquire an ISDN service and have the equipment to fiddle
the CLI

* Your local service provider has to be negligent or poorly equipped
enough to let you set the CLI to something other than those that are
assigned to you.

* When it comes to making 911 calls, the call still has to go through a
local selective router so you have to be in the general area - as
opposed to the other side of the planet.

The foreign companies you are referring to could not call an arbitrary
PSAP simply by setting the CLI to the area code associated with that
PSAP.

I'd call that a significant set of hurdles with a corresponding limited
capability compared to being able to make calls from the other side of
the world whenever you want.

Cheers,

Martin

From: Andrew Newton [mailto:[email-masked]] 
Sent: Wednesday, 28 February 2007 2:43 AM
To: Dawson, Martin
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re:
[Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

PSAP catchment?

Sorry, I meant to say ANI.  But the fact that the ANI is used to get the
ALI is a security issue.

It is especially telling given that there are companies in foreign
countries that specialize in faking US ANIs.  They'll take your credit
card over the web.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 27 Feb 2007 17:24:55 -0500

On Feb 27, 2007, at 4:47 PM, Dawson, Martin wrote:
> * When it comes to making 911 calls, the call still has to go  
> through a local selective router so you have to be in the general  
> area - as opposed to the other side of the planet.
In other words, the solution for the PSTN is physical security...  
meaning that nothing on the scale of what we are talking about has  
been tried and therefore the true cost of failure is unknown.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 27 Feb 2007 18:17:06 -0500

I don't get this Andy.  What Martin told you is that you are very limited in
how you can spoof ANI for 9-1-1; you have to have PRI service in the rate
centers served by the selective router, and your LEC has to be negligent in
policing ANI on the PRIs.  It's not "physical security" as much as it is
routing limitations of selective routers and poor procedures on the part of
some LECs (or maybe it's more like they know what they are doing, no one
stops them, and they are making money doing it).  There are some legislative
efforts underway to stop this.  You can expect some action pretty soon in
the U.S.

Nothing on the scale of wide open unfettered ability for any teenager to
completely fabricate any location he wants on an emergency call with zero
validation has been tried, and the true cost of that failure is indeed
unknown.  You got that right.

Brian

> Sent: Tuesday, February 27, 2007 5:25 PM
> To: Dawson, Martin
> Cc: [email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Tue, 27 Feb 2007 22:10:39 -0500

Andrew,

- If the location provided verbally matches with the automated signed location, all is fine and dispatch ASAP.

- 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).

- If the location provided verbally don't match with the automated un-signed/fail-signed location, be very suspicious before dispatching and flag the call as "untrusted location". Post-call investigation is required.

- If caller can't speak and automated signed location is provided, process the call and dispatch ASAP while flagging it as "unverified location".

- If caller can't speak and automated un-signed/fail-signed location is provided, be very suspicious and flag the call as "untrusted location" before dispatching the police. Post-call investigation is required.

- If the caller hangs-up before providing location verbally and after automated signed location has been provided, call back to validate location else, process the call and dispatch ASAP while flagging it as "unverified location".

- If the caller hangs-up before providing location verbally and after automated un-signed/fail-signed location has been provided, be very suspicious and flag the call as "untrusted location" before dispatching. Post-call investigation is required.

I'm not a call taker and never been in that position but to me, this just makes sense. The signature is yet another piece of information that the call taker can use to make better judgment. He does not solely rely on it but use it in conjunction with other piece of information.

Guy Caron

De : Andrew Newton [mailto:[email-masked]] 
Envoyé : 27 février 2007 11:10
À : Caron, Guy (A162859)
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

Guy,

I'm a little concerned that we are missing some points in this discussion.  Thanks for your patience.

It is my understanding that in all cases where a PSAP is able to talk to a person on the other end of the phone, that they will trust the location given verbally over any automated location regardless of crypto bells and whistles.  The location from the network may get used if the emergency responders cannot use the information given by the caller, but in this case signed location seems of little value.

Where signed location seems to have more validity is in the case where the PSAP cannot talk to the caller, such as a 9-1-1 hang-up.  However, even in this case it wouldn't take more than a few calls an hour for the PSAP to catch on to the problem and change tactics.  So the question comes down to this, can signed location be enough of a differentiation from non-signed or invalidly signed location where a PSAP would quit ignoring calls?  Even with signed location, it is possible to have a coordinated attack within the window necessary to trigger the PSAPs alternate tactics.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 28 Feb 2007 13:50:22 -0500

Brian,

As we've discussed previously.....

You are correct in that *requesting* a digital signature on location objects
will expose the 10 year old with a handheld spoofing their location.  But it
will not stop the 14 year old miscreant with a Linux machine.  One basic
fact is the use of signatures will actually attract the miscreant while at
the same time stop a dispatch based on the 10 year olds spoofed location.
But any dispatcher that has been on the job more than 2 hours will be able
to thwart the 10 year old regardless of signatures, while the miscreant will
appear trustworthy.

What you are doing by accepting calls with and without signatures is
exposing part of the call taker's algorithm for detecting suspicious
callers.  Hence, you are creating a rich(er) attack vector.  In addition you
are creating machinery that risks classifying legitimate callers as
suspicious resulting in a lower grade of service for John Q. Public.

"Sorry, Mr. John Q. Public's estate, due to your calling device performing
self location determination and our policy of not dispatching to un-signed
location objects when busy, even though you were actually at the reported
location, we didn't dispatch.  Instead our responders were sent to the
corner of 1st & Main where there was no emergency, but that call was more
trustworthy due to a valid-at-moment signature on the location object."

I still claim the call taker (human element) is in the best position to
determine suspicious callers and that exposing the algorithm they use in
that determination process is nothing more than hanging a sign on the locked
door of your house telling all which room your money is stored and how much
is there.  There is much to be said about security via obscurity.

Again, signatures have value, but I still claim they don't deliver what has
been promised in this context.  Expectations, good and bad, need to align
with capabilities and ROI.  I've yet to hear the community accept a lower
grade of service for the good guys via a very expensive partial solution to
thwart the bad guys.

-Marc-

> Sent: Tuesday, February 27, 2007 8:01 AM
> To: 'Marc Linsner'; 'Dawson, Martin'
> Cc: 'GEOPRIV'
> Subject: RE: 
> One of the security tenants we live with is that nearly all 
> security mechanisms can be breached if the attacker is 
> skilled enough, or spends enough money.  The attack I want to 
> prevent is a script kiddie sending cops on a wild goose 
> chase.  They do this now with pay phones.  With VoIP, we make 
> it MUCH easier to mount this attack.  I want to get the cost 
> of the attack high enough that it takes a major organized 
> effort costing significant sums.
> 
> Signatures do that.
> 
> we "broke" ANI, PSAPs were pretty immune to spoof of location 
> except from highly organized and well financed groups or very 
> highly skilled hackers.
> With IP endpoints, we have lowered the bar to trivial spoof 
> far too low.  We need to raise it, and signatures will raise 
> it.  We can argue how high the bar gets raised, but without 
> signatures, pretty much anyone who can program can cause an 
> emergency call to appear like it comes from anywhere they 
> want it to.  That bar is too low. 
> 
> I'm not at all happy to drop signatures as a viable way to do 
> that unless you can show that a trivial attack works in the 
> presence of a signature requirement.
> 
> It is a fact that PSAPs believe what they are told.  
> Regardless of what the automatic mechanisms say about 
> location, they go where the caller tells them to go.  
> However, they do know how to handle suspicious calls.  They 
> do know how to back track.  They know how to send back up 
> units.  Suspicion is something they know how to deal with.
> 
> Brian
> 
> > > Properly applied signature security means that each call needs to 
> > > come from a corresponding physical presence in the area 
> of coverage 
> > > of the PSAP.
> > 
> > piece of data that can be launched from *anywhere*.
> > 
> > -Marc-
> >

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 28 Feb 2007 20:03:07 -0600

The only item of substance I see in the below post is the "John Q
Public" paragraph. The rest of it is still focussed on the use of signed
location in real time by the actual dispatcher as some kind of attack
filter - it's not the point, and any filtering that relies on human
interaction is too late. Signed location facilitates automatic policy
application and identifies the location source for later follow-up to
support, among other things, continuous improvement.

The very good point raised is effectively "what about these
self-locating devices?" The classic example is a device with autonomous
GPS and it's as good an example as any. The location dependability
requirement from NENA is what led to the "assertion mechanism" being
defined for HELD for just this purpose. We don't want to rule out such
capabilities since the GPS location may indeed be more accurate than the
LIS can determine. A credible scenario for this is a wireless WAN (WiMAX
or whatever) that can only do a cell-coverage type location
determination where the GPS value is a more precise location within this
coverage area.

The assertion mechanism permits the device to submit its own opinion of
the location as part of the request. The LIS can apply the assertion
test and, if it passes, this location is returned as the actual result.
If it fails, then the LIS returns its opinion of the location. This
provides the simple function of permitting the device to test its own
location determination against that provided by the network. However, it
becomes especially useful when used in conjunction with a signed
location request. Then the result is a signed location either way - and
it will be the device determined location or the LIS determined location
depending on the result of the assertion test. This has some other nice
benefits, such as the fact that the device can do the same thing when it
moves to a wired DSL connection, for example, but this time it can get
the preferable civic address form when that LIS applies its assertion
test.

Beyond simple assertion, HELD also has support for more sophisticated
device capabilities - via the device capability exchange mechanism. This
allows a suitably qualified LIS to, for example, determine that a device
supports SUPL and to bootstrap a SUPL session for the exchange of GPS
assistance data, and pseudo-range measurements for network hybrid
location determination.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Thursday, 1 March 2007 5:50 AM
To: 'Brian Rosen'
Cc: 'GEOPRIV'
Subject: RE:

Brian,

You are correct in that *requesting* a digital signature on location
objects
will expose the 10 year old with a handheld spoofing their location.
But it
will not stop the 14 year old miscreant with a Linux machine.  One basic
fact is the use of signatures will actually attract the miscreant while
at
the same time stop a dispatch based on the 10 year olds spoofed
location.
But any dispatcher that has been on the job more than 2 hours will be
able
to thwart the 10 year old regardless of signatures, while the miscreant
will
appear trustworthy.

callers.  Hence, you are creating a rich(er) attack vector.  In addition

"Sorry, Mr. John Q. Public's estate, due to your calling device
performing
self location determination and our policy of not dispatching to
un-signed
location objects when busy, even though you were actually at the
reported
location, we didn't dispatch.  Instead our responders were sent to the
corner of 1st & Main where there was no emergency, but that call was
more
trustworthy due to a valid-at-moment signature on the location object."

I still claim the call taker (human element) is in the best position to
determine suspicious callers and that exposing the algorithm they use in
that determination process is nothing more than hanging a sign on the
locked
door of your house telling all which room your money is stored and how
much
is there.  There is much to be said about security via obscurity.

Again, signatures have value, but I still claim they don't deliver what
has
been promised in this context.  Expectations, good and bad, need to
align
with capabilities and ROI.  I've yet to hear the community accept a
lower
grade of service for the good guys via a very expensive partial solution
to
thwart the bad guys.

-Marc-