Subject: RE: crypto delay (Notes from Non-meeting)

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 03 Apr 2002 08:27:56 -0500

> > Can you cite any evidence that authentication of the 
> emergency center by
> > the end device is a requirement?
> 
> No. Maybe I misunderstood your original comment about what 
> might generate
> the delay.
> 
> 
> Acatually, I'm not sure whey we spend so much time discussing the
> E911 scenarios, though I'm clearly guilty of doing so myself. 
> The reaction
> time thing just caught my eye.
> 
One of the "users", probably the first user, of the geopriv object
is emergency calls in SIP.  The requirements for emergency calls at the
top level are pretty straightforward, but are clearly subject to
interpretation as you dig down. 

Emergency callers have some expectation of privacy.  That expectation
is presently pretty limited.  There is no harm in providing a higher
level of privacy, provided that you don't screw something up.  Response
time is one of those things that can be screwed up.  Phones, in general,
have fairly puny processors.  SIP phones have beefier processors than
first gen cell phones, and 3G cell phones have processors capable of
non-trivial crypto, but I think we have to keep "fraction of a second 
on embedded cpu" goals when we make crypto choices.  If we are forced
to choose between increased security and increased response time on
emergency calls, it makes sense to me to choose increased security up 
to the point where on a typical SIP phone or 3G handset, you either 
overflow limited memory, or more likely limited MIPS.  The latter is the 
"fraction of a second" kind of thing.  I'm presently worried about it,
but there are others who think there are solutions that achieve
strong assurances within the kinds of time/MIPS/Memory constraints
we deal with.  I'm certainly not oppossed to trying.

I'll conceed the point that it's possible to have the location information
come later than the call completion.  That is undesirable (because
it is actually very interesting to route the call in the emergency center
based on location, something not possible now), but it's concievable.  
It's also not a great way to deal with in in SIP - rather than simply
shoving the location in the INVITE, we have to create a mid call dialog.
That is also possible, if undesirable.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Apr 2002 08:45:02 -0500

I don't think that's a viable option. The location information is used
for two different things:

- selecting the appropriate emergency call center that handles a
particular geographic region (PSAP in the US);

- providing the emergency call center with user location information

Clearly, the first requires location information as part of the call
setup and cannot be deferred until later in the call.

---

From: Marc Linsner <[email-masked]>
Date: Wed, 03 Apr 2002 09:16:48 -0500

Agreed!  With SIP, location information must be in call setup.  Even
Wireless Phase II has issues with this that they have not solved as the
location information lags call setup by several seconds.  In a WPII call,
the PSAP choice is made by simply sending the call to the PSAP that services
'most' of the territory covered by the tower the caller is using.  The PSAP
will then 'transfer' the caller to another PSAP if appropriate.  Not a
choice with SIP as users are not 'tower bound'.

Hmm, maybe we need one PSAP per country............

-Marc Linsner-

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Apr 2002 09:26:58 -0500

> Hmm, maybe we need one PSAP per country............

Yes, I would suggest the IETF be charged with changing the division of
powers between the federal government, the states and localities in the
United States and other countries. This is our core expertise and since
we have an ample budget to finance such a transition, we should get
cracking on this immediately. We'll have to set aside a few million for
a global CA for emergency centers, but the term "unfunded mandate"
hasn't stopped real politicians, either. Would somebody please start by
writing an Internet Draft on how to reorganize the provision of
emergency services so that they better conform to our protocol ideas?

---

From: Adam Shostack <[email-masked]>
Date: Wed, 03 Apr 2002 09:50:36 -0500

> interpretation as you dig down. 

Perhaps this is a mistake?  I think that emergency calling is complex,
and I'm far more concerned about my non-emergency privacy.

(I do think there is a security concern, which is that if I send your
internet phone a hyperlink of the form  "img src=tel:sos" you may hand
out your location without the same meaning as actually dialling 911.
We likely can't cope with this at the protocol level, but should note
it in the security concerns section, and suggest that turning off
privacy preference should be based on user action...)

> we deal with.  I'm certainly not oppossed to trying.

I'm also interested in trying, and would like to throw out the
suggestion that we might specify a level of crypto which is secure,
and offer nothing on slower processors.  That would make sense if we
worry about roll-back attacks, and the ongoing cost of having weak
crypto in the system.

Adam

---

From: Adam Shostack <[email-masked]>
Date: Wed, 03 Apr 2002 14:07:54 -0500

On Wed, Apr 03, 2002 at 02:04:28PM -0500, Richard Shockey wrote:
> A
> Until its you that has the heart attack.

No, even then, I'm more concerned about my privacy outside of the
emergency.  Or are you suggesting that the risks of having my
insurance company know about my eating habits are sufficiently
worrisome that I should worry about the privacy risks of location
phones at all times, even when having the heart attack? ;)

> I'm more concerned that the needs of the emergency response system are not 
> impeded in any form I'm having the heart attack thank you very much 
> ..adding complexity to the task of getting a location object from Point A 
> to Point B is a "bad thing" tm.  KISS strikes me as a more interesting 
> foundation for protocol design.

By "offer nothing" I meant offer no security or privacy for the
location information, not no location information, such that we don't
get bogged down in figuring out what authorization scheme meets the
privacy requirement, the routing requirement, and the speed
requirement.

Adam

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 03 Apr 2002 14:08:07 -0600

>emergency services so that they better conform to our protocol ideas?

In one of those moods today, huh.....

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 03 Apr 2002 14:13:01 -0600

>> is emergency calls in SIP.  
>

Are you suggesting we now are looking at two solutions (because you just broke
the problem up into two problems)?

>and offer nothing on slower processors. 

Now, how is a single protocol (which GEOPRIV is chartered to create) going to
tell the power *and* load of each processor before determining that crypto is
or isn't required? Or am I misreading your comment?

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems

---

From: Adam Shostack <[email-masked]>
Date: Wed, 03 Apr 2002 15:31:57 -0500

> the problem up into two problems)?

I'm suggesting that the emergency use problem may be really hard, and it
may be worth looking at the non-emergency use cases as first user.
Thats still a hard problem, and if we can solve it, we may learn
things that we can apply to the emergency problem.

> or isn't required? Or am I misreading your comment?

I think you're misreading my comment.  Brian suggested that we have to
accomodate the lowest power processors out there with geopriv.  I'm
suggesting that we might design a secure protocol, and if the device
can't accomodate it, too bad.  We can always find a smaller, slower
device, on which someone may reasonably want to run GEOPRIV (say those
Hitachi 1/2 mm chips); should we lower the security of everyone's
system to accomodate those small processors?

Adam

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Apr 2002 17:10:11 -0500

This all has very little do with crypto processing. As the last few
messages tried to show, it's a matter of message exchanges and
reliability.

Emergency calls are probably the single most important reason that
people care about location; most everything else is somewhere between
toy and "nice to have". Basically saying "we'll figure out later if this
works, if not, well, you just have to wait a few years" is not an
acceptable answer, methinks.

The emergency call problem is actually pretty simple. It only gets to be
hard if you put artificial constraints on it that no real user much
cares about (as witnessed by real, existing systems).

---

From: John Morris <[email-masked]>
Date: Wed, 03 Apr 2002 17:38:37 -0500

At 5:10 PM -0500 4/3/02, Henning Schulzrinne wrote:

>.....
>toy and "nice to have".

I can't prove it, but I do not think this is correct.  Emergency 
calls are certainly going to be, initially, the main place where 
location is used in a "critical" manner.  But I doubt that 911/SOS 
location tracking will be the big market driver for these services -- 
I expect that the "nice to have" services will drive deployment of 
location capable devices, and the ability of the services to also 
help out in an emergency will either be a market or (in some places) 
regulatory requirement.

But, in any event, I'm not sure that it makes a key difference here. 
At the end of the day, we need to be able to support emergency 
location tracking while at the same time protect privacy in the "nice 
to have" contexts.  I do not think that the WG will have succeeded if 
we cannot achieve both goals (at least for devices that have a 
moderate amount of processing power).

John

--------------------------------------------------
John Morris // CDT // http://www.cdt.org/standards
--------------------------------------------------

---

From: Adam Shostack <[email-masked]>
Date: Wed, 03 Apr 2002 17:44:50 -0500

> messages tried to show, it's a matter of message exchanges and

I mostly agree.  I do think there's an authorization requirement for
revealing location information when the call may not be what the user
intended.  (Think about a hyperlink that fetches an image from
tel://sos, causing the user to reveal their location to a set of
machines involved in call setup.)

> acceptable answer, methinks.

I care about location because I fully expect that its going to be
revealed all over the place, after its been installed for emergency
use.  I don't see a way to resolve privacy with emergency use; the
constraints may be sufficient that we say "If you think you're calling
an emergency line, turn off all privacy."

> cares about (as witnessed by real, existing systems).

So are there privacy constraints around revealing your information to
what you think is a PSAP that you think you want to dial?  If not,
can the protocol simply state "emergency call: no privacy"?  Do we
need a protocol message for that?  

Adam

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 03 Apr 2002 17:33:33 -0600

>On Wed, Apr 03, 2002 at 05:10:11PM -0500, Henning Schulzrinne wrote:

<snip>
>can the protocol simply state "emergency call: no privacy"?  

This is the position I feel is doable and realistic, others don't feel that way
and aren't in a compromising sort of mood regarding this apparently -- hence
the stalemate. In my more than two years of working on this within the IETF,
there has been ZERO movement on this one item, and until there is -- there will
be no protocol I feel.

>Do we

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Apr 2002 20:22:09 -0500

> machines involved in call setup.)

That's a broken implementation, not a crypto or privacy problem. The SIP
entity would only reveal its location when making a call to sip:sos@...
, sip:911@, etc. I believe you're misunderstanding the mechanism.

Yes, this can be intercepted by a bogus proxy that you might be
visiting. However, if you're in the network housing the bogus proxy, the
network probably can find out which Ethernet jack you're using or which
802.11 AP you are coming in on and sell that information to the highest
bidder. If a proxy that does 911/sos routing does something illegal with
the location information, that is probably as much a ground for
prosecution as it would be if your local 911 operator went spouting off
to neighbors about the suicidal caller she got that day.

If you're paranoid and the firewall in the visited network allows it,
you would tunnel to your home proxy via TLS. The home proxy would then
route the call, based on the location information. If you use
sips:sos@home, you'd even get TLS from the home proxy to the PSAP. I
think that this would be much more effective than a special CA for PSAPs
or a special encryption for location information. To spell this out in
more detail:

- my emergency call from any visited network goes TLS to home proxy (in
my case, cs.columbia.edu), affording message privacy and server
authentication;

- cs.columbia.edu home proxy finds appropriate PSAP based on location
information;

- home proxy routes request to PSAP (and verifies its identity) using
TLS

This requires no CA for PSAPs, only a database that's trusted. There are
a number of companies that offer such databases (references available
upon request) that map location information to jurisdictional
information. As long as you can trust these providers, this is at least
as good as a CA would be, minus the PKI issues.

This illustrates that geo-specific privacy would add no appreciable
privacy value, but increase complexity and add failure modes.

Less paranoid individuals may use other permutations; I'm not enough of
a nanny that I would want to prescribe what people do.

> an emergency line, turn off all privacy."

This doesn't have to be "turn off all privacy". See above.

> need a protocol message for that?

Again, there is this strange notion of a protocol "message". In this
case, there are no separate messages. Location information has to be an
integral part of the session setup, as it determines the route the
session setup takes.

---

From: Randy Bush <[email-masked]>
Date: Thu, 04 Apr 2002 15:49:16 +0200

> Until its you that has the heart attack.

i have had it.  i still value my privacy.

thanks for playing.

randy

---

From: Andrew Daviel <[email-masked]>
Date: Thu, 04 Apr 2002 10:24:51 -0800 (PST)

> Until its you that has the heart attack.

If, due to weakened security/crypto/authentication, someone is able to
play games with the E911 system, the emergency services may be too busy
chasing their tail to attend to your heart attack. The BAT/911-A virus
attempted to do this in April 2000 on PCs, and the more complex and
capable mobile devices become, the greater risk that they could also
be infected with a virus. There is also the possibility of a deliberate
act of sabotage. (I'm not sure how much protection you would get against a
virus actually in the mobile device, but you may be able to protect
against spoofing from outside)

Realistically, the only thing that we can deliver in a few seconds is
information such as first aid advice, and that doesn't need location
information. However, I concede the point about call routing.

Moores Law will surely bring us mobile devices with enough power to
do whatever crypto is necessary, maybe even by the time the protocol is
ready. There is a limit to offering enhanced service on obsolete devices
- if the device is too old to have location capability, then you can't di
it at all. (I believe that as device speed rises, so does the
required key length for crypto to be considered secure, but that the
time to crack a key of length N rises exponentially in N while the time to
generate it rises with a power of N, so that to keep crack time out of
reach it necessary only to increase N with log(speed) - so Moore's law
wins (with current theory) and reliable crypto gets quicker and quicker)

The only way we would be able to deliver emergency services fast enough to
make a real difference - prefereably within 60 seconds - would be
to locate someone qualified who is already nearby, and call them. This
might actually be doable with the technology. It happens somewhat with the
Coast Guard - someone calls on VHF 16 to say they are on fire, or sinking,
the Coast Guard starts a dialogue with them to find out where they are
etc. then rebroadcasts a call for assistance to anyone in the area, given
that they themsleves would take at least 20 minutes to arrive.

All adults whould be trained for simple emergencies - CPR, first aid,
fire fighting, etc. - so that bystanders or family members are your best
bet until more qualified help can arrive.

-- 
Andrew Daviel
Vancouver Webpages
(aka [email-masked])

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 04 Apr 2002 15:35:53 -0600

At 10:24 AM 4/4/2002 -0800, Andrew Daviel wrote:
<snip>
>required key length for crypto to be considered secure,

I disagree here. Regarding a non-stationary or static piece of information
(national secret type) , a 128 bit key length should be sufficient if used by a
good encryption algorithm. I submit if that key length isn't good enough, a new
algorithm should be chosen, not a new key length.

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems

---

From: Randall Gellens <[email-masked]>
Date: Thu, 04 Apr 2002 17:36:44 -0800

At 10:24 AM -0800 4/4/02, Andrew Daviel wrote:

>There is a limit to offering enhanced service on obsolete devices
>it at all.

There are handsets and other devices now with built-in GPS and/or 
network-derived/network-assisted location determination.  The devices 
are often still very much memory and CPU constrained.

---

From: Richard Shockey <[email-masked]>
Date: Wed, 03 Apr 2002 14:04:28 -0500

A

Now on to other things..

What is the location object be are all talking about ?  XML? ASN.1 <just 
kidding>

What is the semantical expression of location object the PSAP needs? 
Typically it keys a database look up based on TN to address.   PSAP address 
databases are simply subsets of LIDB or DA information supplied by the 
LEC's this is now complicated by the mobile environment where formal 
Lattitude and Longitude are used ..again keyed to address.

So in those environments where E.164 addressing is uesd that is a 
requirement...not we have the problem of sip URI's

Now what other paramaters does it need to transmit?

TTL?

Confidence  Factor ? By this I mean ..whatever system generates the 
location information may be able to transmit its Confidence in the 
reliability of the data. This might be useful in those cases where L/L 
triangulation is difficult or is unable to reach pinpoint accuracy.

I'm just thinking out loud about what could or should not be included in 
the object.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<