Subject: RE: [Geopriv] Geopriv for emergency calls

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 18 Nov 2003 17:31:54 +0100

hi henning, 

please see my comments inline. 

> > you argue that this message communication is not 
> end-to-end. why do you
> > think that end-to-end security is then problematic?
> > 
> > i assume you would like to avoid asymmetric cryptographic 
> algorithms.
> > 
> > does the originating terminal (sip phone) know which entity 
> is going perform
> > cryptographic verification?
> > 
> 
> No - that's the whole point (unless you assume that all 
> emergency call 
> centers share the same private/public key pair, which is 
> clearly not a 
> good idea).

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. 

in any case i see the problem of a public key based approach. in general i
think that the problems are always there if you use s/mime for a client. you
need a client-side pki. 

i fully understand that you would like to reuse existing security of the
using protocol instead of using something different for the location object
only. particularly for some architectures where sip is used this might be a
problem. 

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?

> You address the message to an abstract entity, but the 
> recipient may, depending on your location, be any of thousands of 
> emergency call centers, all operated by different 
> governmental entities.
> 
> Redirection can solve some of these problems, but it does add 
> significant delay if you have to traverse the wireless 
> channel several 
> times and transmit a large (signed) object across it or have 
> to set up 
> an on-demand TLS connection with the multiple round-trip times that 
> requires.
> 
> (Redirection = contact locally trusted proxy that then tells you the 
> identity and public key of the ECC, so that you can send e2e 
> encrypted 
> material. This assumes that there is a directory of such ECCs that is 
> being made available to the public. This, unfortunately, may 
> or may not 
> happen; I'm working within NENA to convince people that they 
> should, but 
> calling this an uphill struggle is an understatement.)
> 
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 

> 
> > is it sufficient to protect the location object to the 
> first entity (e.g.,
> > first sip proxy) only? is there are strong trust 
> relationship between the
> > entities in the network which need to inspect location 
> information for the
> > purpose of routing the call?
> 
> Depends on what you define by trust. You pretty much have to 
> trust your 
> outbound proxy, as it can probably just refuse to open the 
> firewall for 
> you and it needs to be able to inspect the destination 
> address.

this is an important question. 
you certainly trust your outbound proxy (and the entire network to some
extend). they have to process your sip signaling message, they interact with
the aaa infrastructure, the charge you, etc. 

in a typical architecture where sip is used there is a considerable trust
between the end host and the "visited network" to act according to the
specified rules. 
 
 It knows 
> your network attachment point, so it probably has a good idea 
> about your 
> location in any event.

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. 

> 
> The outbound proxy will then likely contact some kind of proxy or 
> redirect server that has knowledge of the geo-to-ECC mapping. 
> While no 
> such entities exist today in the IP arena, it seems 
> reasonable to assume 
> that they will be operated by either a government agency or a 
> delegate 
> (some private company or not-for-profit operating the service on a 
> contract basis). In the PSTN, the model is similar, with the 
> 'selective 
> router' filling that role, operated typically by the ILEC in 
> the US, on 
> a PUC-regulated basis.
> 
> 
> > this sounds very useful for me. in order to protect the 
> location object
> > against eavesdroppers it has to be encrypted. 
> > this needs to be considered. 
> 
> Presumably channel security such as TLS can satisfy this need.

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. 

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. 

> 
> > 
> > i think that it might be difficult to mandate s/mime 
> protection everywhere
> > particularly since you might already protect sip signaling 
> (or other using
> > protocols) already. considering this issue in light of the 
> using protocol
> > might be useful. 
> > 
> 

ciao
hannes

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 18 Nov 2003 15:52:48 -0500

> and/or the emergency call center would need to verify your digital

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.

> 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?)

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

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

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

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