Re: [Geopriv] Geopriv for emergency calls

From: Henning Schulzrinne ^lt;hgs@cs.columbia.edu>
Date: Tue Nov 18 2003 - 15:52:48 EST

> depending on the type of security (symmetric/asymmetric, digital signature,
> encryption) you would need to know the public key of the a possibly
> "virtual" emergency call center
> and/or the emergency call center would need to verify your digital
> signature.

We've discussed this a few times. It assumes that there is a single
global entity that is trusted by all users not to reveal information to
'bad' parties. In the absence of a world government, this would be the
United Nations. In the US, such notions bring out the black helicopter
crowd.

> this problem questions the decision to "use s/mime" (or use application
> layer security) for protection of the location object. would you like to
> reconsider the question of securing the location object by taking the using
> protocol into consideration?

I think this would be practically useful given the absence of a public
key distribution and discovery mechanism for S/MIME, but if we agree
that policy only requires a secure channel for emergency call use, I can
live with that.

(My understanding is that S/MIME for email typically populates the
public key repository at the sender by first receiving an email from my
correspondence partner. This message contains the public key signed by a
mutually trusted CA. Is that true?)

> if you assume that some security is already established between the end host
> and the first-hop proxy and if you furthermore assume that there is a trust
> relationship between the network of the first-hop proxy and the emergency
> center then i think you could
> - use the previously established security association to protect the
> location object (and the entire sip signaling)
> - provide the authenticated entity to the emergency center(s)
> - detect fraud/misuse easily

Correct, with one caveat. Generally, in emergency calling,
authentication of the caller is a secondary concern. For example, in
most jurisdictions, you can place an emergency call from a payphone. (I
say 'most', since I've heard that there are innercity areas where police
is not dispatched based on payphone calls since that has been used to
set up ambushes for the usual two-cop team that responds to a call.)

In this model, the first-hop proxy has gotten the call routing table
from a presumably trustworthy source and thus only needs to assure that
it is indeed talking to the right next-hop rather than the local Mafia
"sure, we'll send somebody right away" impersonator.

> not necessarily. a sip proxy could be located in my home network. i use an
> ipsec tunnel to connect to the network. it would have to assume that i am in
> the local network which is not true.

Note that I said 'probably', not 'always'. I think we all agree that
there are many VPN-style cases where that is not the case. An
ill-intentioned visited network could, however, easily prevent you from
placing emergency calls except if you talk to its outbound proxy.

> from your description i also get this impression. tls provides encryption
> capabilities which protects the location object from eavesdropping. http
> digest does not provide the same capabilities which might be a problem.

I see no major role for HTTP Digest in this scenario and I don't think
either Brian or I mentioned this in this context. See notes on caller
(not callee) authentication above. Naturally, the outbound proxy may
require Digest authentication, as per standard SIP operation. It is a
SIP question as to whether an outbound proxy should attempt such
authentication or just pass the emergency call to the ECC. (By the laws
of the jurisdictions that I'm familiar with, the outbound proxy would
have to allow the call to get through even if authentication fails.)

>
> in order to handle emergency calls it is necessary to deal with
> architectural aspects (which go beyond protocol interaction). adding a
> description to a draft might certainly help to integrate the functionality
> of emergency calls in an architecture appropriately.

Brian and I are planning to write such a draft that follows the rough
model that Brian and the subsequent discussion thread has outlined. The
discussion here serves (from my perspective) to avoid wasting our time
on writing the draft if that approach is considered inappropriate.

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue Nov 18 15:54:26 2003

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:24 EST