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

[Matt Lepinski <mlepinski at bbn.com>]

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:

Brian Rosen wrote:

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



_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv