RE: [Geopriv] HELD and persistent TLS connections in emergency calls
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Geopriv] HELD and persistent TLS connections in emergency calls
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
> -----Original Message-----
> From: Matt Lepinski [mailto:mlepinski at bbn.com]
> Sent: Friday, September 14, 2007 3:14 PM
> To: Brian Rosen
> Cc: 'GEOPRIV'
> Subject: Re: [Geopriv] HELD and persistent TLS connections in emergency
> calls
>
> 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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.