Subject: RE: Security Concerns with Emergency uses of Geo Location

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 13 Jul 2001 16:41:48 -0400

> > However, geolocation is a very vital piece of information
> > in an emergency; it is REQUIRED information (legally in some
> > cases).  However, emergencies arise in circumstances where
> > authentication is not practical.
> 
> Then by all means contribute to the standardization work and 
> make sure these
> needs are taken care of.
I am, I will.

> 
> > ...
> 
> > In terms of requirements:
> > 1. entities which have location information and place
> > emergency calls where location is required to be reported must
> > be able to send such location without requiring user
> > identity or any other form of authentication not provisionable
> > in the end device itself.
> 
> Nothing in the charter says that user identity will be required in all
> cases.
Sure, but the charter isn't a requirements document.
Are we writing one?

> 
> > 2. PSAPs must be able to request location of any device
> > placing an emergency call from any service that has such
> > location.  The PSAP must authenticate itself as a PSAP.
> 
> Exactly. In this case authentication still occurs, it is just 
> the callee
> being authenticated, not the caller.
Yes but many authentication mechanisms imply mutual authentication.
So this has an impact on choice of mechanisms.  I agree this is
doable.

> 
> > 3. End devices placing emergency calls must be able to request
> > its own location from any service that has such location without
> > requiring user identity of any other form of authentication
> > not provisionable in the end device itself.
> 
> This is harder, but still not impossible. An end device in 
> such a situation
> has the credential provided to it by the emergency service it 
> has contacted.
> That credential could be designed in such a way that it could 
> be used by
> proxy to obtain location information from another service.
I hadn't thought of this, but it might work if it had a
use-once characteristic.

> 
> > 4. Any privacy control mechanisms specified as required in
> > emergency calls must be able to be completed in an expeditious
> > manner, when conditions are far from ideal (consider disaster
> > situations, for example).  Thus the choice of mechanisms and
> > algorithms must take into account impaired networks, etc.
> 
> In general privacy control mechanisms should be as light 
> weight as possible.
> So while I agree that this is something to consider, I don't see it as
> a concern unless we seem to be getting into trouble.
I see a lot of reason to be concerned.

A good example is that sip is normally UDP based.  Take a
UDP based mechanism and send a big cert on a system with 80%
packet loss and a constrained bandwidth and tell me how long it will take to
get authenticated.

If it's a 200 byte token, no problem.

Ask anyone who is waiting for the emergency operator's phone
to ring how much he cares about authentication.

Brian

---

From: [email-masked]
Date: Fri, 13 Jul 2001 15:19:22 -0700 (PDT)

> Sure, but the charter isn't a requirements document.

On the contrary, the charter most certainly is a requirements document. It
describes what the WG is required to do in order to be successful. I actually
think of it as a kind of contract. Done right charters can be wonderfully
focusing and can prevent WGs from wandering off into the weeds.

> Are we writing one?

Whether or not the requirements warrant a separate document is up to the WG
chairs to decide.

> > the callee being authenticated, not the caller.

> Yes but many authentication mechanisms imply mutual authentication.

And many don't.

You seem to be assuming that our fairly restrictive charter is going to force
us to design something that doesn't meet your needs. But after many years of
experience in the IETF, I've found that often exactly the opposite happens: By
making security paramount we avoid having a lot of nonproductive debate
about proposals with totally inadequate security.

> So this has an impact on choice of mechanisms.

Of course.

> I agree this is doable.

Good.

> > This is harder, but still not impossible. An end device in such a
> > situation has the credential provided to it by the emergency service it
> > has contacted. That credential could be designed in such a way that it could
> > be used by proxy to obtain location information from another service.

> > In general privacy control mechanisms should be as light weight as
> > possible. So while I agree that this is something to consider, I don't
> > see it as a concern unless we seem to be getting into trouble.

> If it's a 200 byte token, no problem.

Again you seem to be assuming that security requirements will force us into
using the wrong mechanisms. And again I've often observed exactly the opposite
to be true: The biggest messes we have are when security is tacked on as an
afterthought. That's when you end up with a large, cumbersome, and somewhat
inappropriate security building block being rammed in heedless of the
consequences.

> to ring how much he cares about authentication.

Actually, he may care a lot. Examples abound where exposure of information
about emergency situations is a very serious concern in its own right.

				Ned

---

From: Andrew Daviel <[email-masked]>
Date: Sat, 14 Jul 2001 05:19:49 -0700 (PDT)

> about emergency situations is a very serious concern in its own right.

I'd think that authentication was a significant issue for false alarms
etc. While the cost of responding to a false 911 call in a city may be a
few thousand dollars absorbed into general expenses, the cost of
responding to a false EPIRB at sea might be millions, while backcountry
searches are not inexpensive either.
(http://www.epirb.de seems good)

Landline 911 calls are authenticated by caller ID. Mobile calls too, I
imagine.

(are we all North American ? I know it's 999 in the UK and something else
in a new European standard...)

Andrew

---

From: [email-masked]
Date: Sat, 14 Jul 2001 08:12:47 -0700 (PDT)

This is starting to drift off-topic so this will be my final posting
on the subject.

> (http://www.epirb.de seems good)

First of all, the concern I was responding to was exposure of information, not
authentication of information per se. Second, the case I was thinking of was
eavesdropping on emergency location information for nefarious purposes. All
sorts of criminal activity could be facilitated by knowing where an emergency
is occurring, especially when that information is available before emergency
services have a chance to respond.

				Ned

---

From: Dominic Pinto <[email-masked]>
Date: Tue, 17 Jul 2001 09:58:11 +0100

> (http://www.epirb.de seems good)

False calls are a significant problem, but likely deliberately made
(false alarms made to the fire service, calls say in Northern Ireland to
draw the police and/or army into ambushes, etc) or, according to reports
in the last year by emergency services in the UK, by people for trivial
or non-serious conditions (ambulances being called for because people
have a temperature). The call may be false, but the location from where
the call is made is not in question.

With the mobile environment, geographic location needs to be established
to ensure a response to the right general location, assuming originating
line identification is being generated. But correct identification of
the mobile is not sufficient. With GSM, at least, as I understand it the
network operator provides triangulation data to locate the mobile. Iff
this is off-shore, there may be less certainty as to location, and there
can be difficulties in border areas. For example, UK mobiles operating
on the northern French coast near Calais are well within range of UK
base stations. There may well be some delay whilst Dover Police catch
the fast ferry to respond to an emergency on Cap Griz Nez or Cap Blanc
Nez :-) .
 
> Landline 911 calls are authenticated by caller ID. Mobile calls too, I

'Authenticated' is not quite the right description. A presented number
may
well be that of the line or mobile. But of course users may chose to
suppress the number (but still available on calls to the emergency
services?) and more importantly PBXs may well be set up only to present
one, main, incoming number (and quite possibly this will be for a number
of linked, geographically dispersed networks). For one system I know of
directly, the presented number is 0+ the PBX extension number.

I believe all UK fixed and mobile networks now support originating line
identification. 
 
> in a new European standard...)

999 and 112 in the UK, 112 throughout the European Union (plus
additional local options like the UK's longstanding 999). I'm not sure
of the wider European Economic Area, or candidate countries for EU
membership, or wider than that.

As a very least requirement, calls to the emergency services must be
enabled......

Of course, knowledge of from where an emergency call is made does not of
itself provide any information about the identity of the caller, but
perhaps (linked to mobile operator and virtual operator, and retailer,
records) information as to the identity of the 'owner' - and if a
corporate/organisation user this may only provide centralised billing
records. The identity of the ultimate user will likely be buried in
personnel records. 

-- 
Dominic Pinto
-------------
Associate Director @ TCUK		| Barn Cottage, Hill House
Senior Associate Telesphere Limited	| Somerton Road, Souldern
http://www.telespherelimited.com	| Bicester, Oxon, OX25 6LS, UK	
----------------------------------------------------------------------
Ph/Fax: +44 1869 346375 Cellphone/GSM Mobile: +44 780 302 8268
----------------------------------------------------------------------
Were you a student at the University of Newcastle upon Tyne?
Register now on 'NUgrad'  - YOUR interactive on-line
database - at  http://www.ncl.ac.uk/alumni/NUgrad
----------------------------------------------------------------------
Check out the 40th European Telecommunications Conference Barcelona 
Spain August 21st - 25th 2001 '2001 European Odyssey - 
Telecommunications in the e-society' at http://www.fitce.org
----------------------------------------------------------------------
The Internet should be for Everyone - help make it so by joining the 
Internet Society ISOC - http://www.england.isoc.org
----------------------------------------------------------------------
"This e-mail, and the information it contains or is attached to it, is
private and confidential and is intended for the addressee only.  The
unauthorised use, modification, disclosure, copying or distribution of
this e-mail or any of the information it contains or is attached to it
is prohibited and may be unlawful. If you are not the intended
recipient, please notify the sender immediately."