Subject: [Geopriv] HELD and persistent TLS connections in emergency calls

From: "Brian Rosen" <[email-masked]>
Date: Fri, 14 Sep 2007 13:34:13 -0400

One of the uses for HELD is for an end device to obtain its location.  The
recommendations in ecrit-phonebcp say that the end device should get its
location when it boots, periodically thereafter, and as it makes an
emergency call.  The time to complete the operation doesn't matter in the
first two cases, but does at call time.

Location sent by value should be protected from eavesdropping.  TLS is of
course the mechanism of choice for HELD. Unless we change our position,
we've stated that the security of the reference is the same as the value.
That means getting a reference doesn't help; you would want to protect the
transfer of the reference with TLS.

What should the recommendation be for the TLS connection between the
endpoint and the HELD server?  Seems like we have two bad choices:
1. The endpoint maintains a persistent TLS connection.  This seems
impossible for a LIS to maintain, and wasteful for the device
2. We incur very long time to establish the TLS session at call time.  I
think this is currently something in the 1/2 second or more range for a
typical phone like embedded controller, sometimes much more.  That is WAY
too long for emergency call, where we're attempting to keep call set up in
the 2 seconds from dial to ring.

I don't have an answer here.  We don't use TLS with the other LCPs; we have
other mechanisms that protect the privacy to various degrees.  TLS is an
excellent mechanism for this purpose.  I just don't know how to deal with
the setup time.

Brian

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 14 Sep 2007 13:54:36 -0400

There are well-known ways to reduce the cost of TLS establishment. I  
think this is called session resumption, but I'm not a TLS expert.

The cost on the device for maintaining a TLS session is essentially  
zero, since no packets are exchanged while idle and devices are  
unlikely to hold more than a handful of connections.

I would not rule out maintaining TLS connections; this is mainly a  
memory issue. We're doing measurements on SIP scaling, with hundreds  
of thousands of open (TCP) connections on a single server.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 14 Sep 2007 13:10:59 -0500

There needs to be a way for a mobile endpoint to end a persistent TLS 
session when it moves to another LIS, if that happens - otherwise a 
LIS is going to have a bunch of sessions with no other end to 
communicate with, right?

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 14 Sep 2007 14:22:44 -0400

I strongly suspect that LIS operators would balk at the idea of
maintaining persistent TLS connections for this. The threat of potential
attack within a tightly controlled access network has not been proven to
be sufficiently probable to warrant the added expense. Possible, yes.
But there is nothing to show that it's probable. I think it's more
likely that someone gets a Trojan on their device that captures the
location and sends it out, than it is likely that the device to LIS
communication is sniffed.
Barbara

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, September 14, 2007 1:55 PM
To: Brian Rosen
Cc: 'GEOPRIV'
Subject: Re: [Geopriv] HELD and persistent TLS connections in emergency
calls

Henning

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: Matt Lepinski <[email-masked]>
Date: Fri, 14 Sep 2007 15:14:09 -0400

Brian,

First, I agree with Henning that RFC 4507 (TLS session resumption 
without server-side state) is an appropriate mechanism to use in 
acquiring location from a HELD server for use in an emergency call. (The 
session resumption mechanism allows a client to keep state which it can 
use to re-establish a session to the same server without doing a full 
TLS handshake.) However, I imagine that Barbara is correct that in some 
deployment scenarios operators will decide that the risk of 
eavesdropping on the connection from device to HELD server is not large 
enough to justify the use of TLS. Nonetheless, it is surely appropriate 
for ecrit-phonebcp to recommend the use of TLS (with RFC 4507 session 
resumption).

Second, with regard to the following comment:

>transfer of the reference with TLS.
I assume that "we" in this case means Ecrit and not Geopriv. The current 
version of the Geopriv location-by-reference document indicates that a 
deference mechanism MUST support authentication upon de-reference. This 
seems appropriate because, in general, the location server may need to 
know the identity of the party doing the deference in order to properly 
apply the privacy rules. I understand that in the context of emergency 
calls that there may be public safety concerns that necessitate 
unauthenticated deference, but surely this is not true in general.

- Matt Lepinski :->

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 14 Sep 2007 15:23:36 -0400

Matt

Since the target of a reference doesn't know what kind of credentials the
LIS will require, and has no way to control that, I think in Geopriv, we
would have to say that the reference must be treated with the same security
considerations as the value.

Brian

> From: Matt Lepinski [mailto:[email-masked]]
> Sent: Friday, September 14, 2007 3:14 PM
> To: Brian Rosen
> Cc: 'GEOPRIV'

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 14 Sep 2007 12:25:57 -0700

Few random thoughts....

Certainly session resumption might work well here - basically when  
the device connected the first time it would do the public key  
operation to set up session once then save a secret that could be  
used for future sessions without doing the expensive public key  
operations. There are extensions to allow session resumption to only  
store state on the client not server - RFC 4507 and soon to be  
approved update to it. It would be well worth having a look at the  
session resumption stuff and seeing how to specify it's usage - it is  
implemented in many TLS stacks including OpenSSL.

I also think it would be worth looking at what the time to set up a  
TLS session is. The first thing would be to look at what size keys  
should the server use - some recommendation for key size specific to  
LIS might help keep people from using things way too large. The  
information transfered over HELD is unlikely to have high long term  
value and that might change the key sizes chosen. It would then be  
good to guess what the processors might be on the very low end stuff  
by the time any of this actually gets deployed. My gut feeling is 1/2  
second does not sound quite right. Whatever the answer is, it would  
be nice to see this analysis.

I can also imagine that in some cases getting a reference might help  
in that the host that eventually fetched the reference might have a  
much faster processor than a low end mobile phone.

Cullen <with my individual hat on>

PS - I simultaneously agree with Henning that it might be possible to  
use long lived TLS connection while agreeing with Barbara that  
regardless of the feasibility, operators will hate the idea. Hows  
that for being on the fence :-)  But I hope we can avoid having to do  
this approach.

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 14 Sep 2007 16:30:22 -0500

This is possible James, but it does depend a lot on how you configure
LIS and what kinds of network you are in. If the LIS can get information
about a device leaving the network then the problem is fairly much
resolved.

Cheers
James

> From: James M. Polk [mailto:[email-masked]]
> Sent: Saturday, 15 September 2007 4:11 AM
> To: Henning Schulzrinne; Brian Rosen
> Cc: 'GEOPRIV'

------------------------------------------------------------------------------------------------
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: Henning Schulzrinne <[email-masked]>
Date: Fri, 14 Sep 2007 17:57:25 -0400

This may be (barely) true for DSL, but is probably not a safe  
assumption for 802.11. On the other hand, 802.11 location isn't all  
that interesting unless there's triangulation, since everybody will  
get the same (obvious) location of the AP.

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 14 Sep 2007 17:16:19 -0500

It is unclear to me at least why we are so worried about the potential
500ms to get setup the location session, when there are at least 2 other
TLS SIP sessions to be established, plus a LoST connection from the
call-server to check the authenticity of the destination as well.

This seems somewhat moot since without valid location you are either not
going route at all, or you are going to misroute.

> Sent: Saturday, 15 September 2007 7:57 AM
> To: Stark, Barbara
> Cc: GEOPRIV

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 14 Sep 2007 17:23:26 -0500

Henning - .11 triangulation is farther along that you are eluding to, 
and will not be a rare observation, at least in public places.  Home 
networks with only a single antenna won't use triangulation, but 
there are other means being worked on to know what distance and 
vector an endpoint is at (with respect to where the single AP is).

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 15 Sep 2007 10:27:11 +0200

Hi Brian,

I agree that this is a challenging question.

I believe for a cellular access network it is challenging to 
periodically fetch location information (given that you may only have an 
emergency call once in your lifetime) and to keep a TCP connection up 
and running all the time.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 15 Sep 2007 10:38:26 +0200

Hi Henning,

>> think this is called session resumption, but I'm not a TLS expert.
This entirely correct. TLS session resumption would certainly help in 
this case. For the performance read here:
http://pages.cs.wisc.edu/~cao/WISP98/final-versions/artg.ps
(I am sure that there are better and more recent papers but I have to 
search a bit...)

Even better, there is also http://tools.ietf.org/html/rfc4507 "Transport 
Layer Security (TLS) Session Resumption without Server-Side State" that 
provides session resumption without keeping state at the server. 
Performance data can be found here:
http://crypto.stanford.edu/~dabo/abstracts/fasttrack.html

Maybe that's something we should consider for HELD to provide a scalable 
and lightweight solution

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 15 Sep 2007 11:00:36 +0200

Hi Cullen,

Cullen Jennings wrote:
>
> Few random thoughts....
>
> Certainly session resumption might work well here - basically when the 
> device connected the first time it would do the public key operation 
> to set up session once then save a secret that could be used for 
> future sessions without doing the expensive public key operations. 
> There are extensions to allow session resumption to only store state 
> on the client not server - RFC 4507 and soon to be approved update to it.

Yep; http://www.ietf.org/internet-drafts/draft-salowey-tls-rfc4507bis-01.txt
(Document already in *RFC Ed Queue*)

> It would be well worth having a look at the session resumption stuff 
> and seeing how to specify it's usage - it is implemented in many TLS 
> stacks including OpenSSL.
>
> TLS session is.

We have done some performance measurements, see
http://www.tmg.informatik.uni-goettingen.de/publications/1297/psk_tls_gi2006_final.pdf

The analysis did not consider session resumption. However, as one can 
easily see the key length and the selected mode has an impact on the 
performance.

> The first thing would be to look at what size keys should the server 
> use - some recommendation for key size specific to LIS might help keep 
> people from using things way too large. The information transfered 
> over HELD is unlikely to have high long term value and that might 
> change the key sizes chosen. It would then be good to guess what the 
> processors might be on the very low end stuff by the time any of this 
> actually gets deployed. My gut feeling is 1/2 second does not sound 
> quite right. Whatever the answer is, it would be nice to see this 
> analysis.
While the above-mentioned study consider "low-end machines" as well it 
did not focus on mobile phones. Maybe that's something to add.

With the low-end servers we have used 1/2 second is certainly not correct.

Ciao
Hannes

> regardless of the feasibility, operators will hate the idea. Hows that 
> for being on the fence :-)  But I hope we can avoid having to do this 
> approach.
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 15 Sep 2007 11:00:51 +0200

Hi Matt,

> I assume that "we" in this case means Ecrit and not Geopriv. The 
> current version of the Geopriv location-by-reference document 
> indicates that a deference mechanism MUST support authentication upon 
> de-reference. This seems appropriate because, in general, the location 
> server may need to know the identity of the party doing the deference 
> in order to properly apply the privacy rules. I understand that in the 
> context of emergency calls that there may be public safety concerns 
> that necessitate unauthenticated deference, but surely this is not 
> true in general.
>
The dereferencing protocol is a separate story. I believe that Brian was 
primarily talking about the exchange between the end host and the LIS to 
retrieve either an LbyV or an LbyR.

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 15 Sep 2007 10:15:12 -0400

The two other TLS sessions (actually there are more) are endpoint to proxy
and proxy to ESRP (the ESRP will have connections to the PSAP and the PSAP
to the call taker.  The ESRP may have one or more ESRPs in the path to the
PSAP).  All of those will normally have persistent TLS connections because
there will be occasional traffic on all of them.

Of course every proxy will not have persistent TLS connections to every
ESRP.  It will only keep connections to ESRPs it regularly deals with, which
I assume would just be experiential based on traffic.  The horsepower on the
proxy to proxy connections makes the cost of the TLS establishment smaller
than on an endpoint.  The statistics for call completion time will be fine
if this connection caching mechanism works.

The LoST connection is somewhat more interesting.  I think the TLS
resumption mechanism in 4507 (thanks all for the reference, I think that is
the answer to the original question) will work here.  At one point we were
wondering about if we needed the same level of security since there was no
identity information in the LoST query, but I think in practice that a query
from a random endpoint to LoST could be assumed to be with its own location,
and thus probably in need of privacy.

That, of course, is an ecrit question, which is why I didn't raise it in the
original email.  I assumed we would use the same solution.

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Friday, September 14, 2007 6:16 PM
> To: Henning Schulzrinne; Stark, Barbara
> Cc: GEOPRIV
> Subject: RE: [Geopriv] HELD and persistent TLS connections in emergency
> calls
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 16 Sep 2007 11:53:24 +0200

In many cases, all of these connections are going to be existing already 
and are essentially 'nailed up'. For example, the proxy would have a 
long-term connection to the LoST resolver.

I don't know what a call server is.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 16 Sep 2007 12:09:06 +0200

I suspect that location usage will be fairly constant and common. For an 
interesting article on using location on cell phones, see the recent 
issue of Pervasive Computing on Navitime (http://www.navitime.co.jp/), a 
pedestrian navigation system. Given the update frequencies needed, HELD 
(or DHCP) is extremely unlikely, however. My guess is that in a few 
years, many cell phones will be using GPS more or less continuously, for 
either in-vehicle navigation with traffic alerts or, in countries with 
usable public transportation systems, for commute optimization.

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 16 Sep 2007 05:09:20 -0500

A call-server is the proxy in the way you are describing it.
I would point out though, that the session between the proxy and the
LoST resolver, does not mean that there is a 'nailed up' session all the
way to the local LoST server, which may still require a session to be
established, and certainly will until the network is fully meshed.
Further more, if the end-point has to do a LoST look up prior to
originating the call, as is suggested by phone BCP, then the problem
still exists.

I think, rather than saying 'hey this is bad', we need a far more
holistic view and not impose totally ridiculous 'out of thin air' time
requirements such as those that have been put forward thus far.

Cheers
James

> Sent: Sunday, 16 September 2007 7:53 PM
> To: GEOPRIV