Subject: RE: [Geopriv] Geopriv for emergency calls

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 18 Nov 2003 10:54:03 -0500

Just for completeness, I agree with Henning on all points.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, November 18, 2003 9:24 AM
> To: Tschofenig Hannes
> Cc: 'Rosen, Brian'; [email-masked]'
> Subject: Re: [Geopriv] Geopriv for emergency calls
> 
> 
> > 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). 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.)
> 
> 
> > 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. It knows 
> your network attachment point, so it probably has a good idea 
> about your 
> location in any event.
> 
> 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.
> 
> > 
> > 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. 
> > 
> 

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 18 Nov 2003 16:21:12 -0500

The only thing I want to add to this is that I think it would be best
if we specifically carved out an exception to "use S/MIME" for emergency
call that is narrowly defined.  Also note that S/MIME remains "MUST
IMPLEMENT".

Brian

> Sent: Tuesday, November 18, 2003 3:53 PM
> To: Tschofenig Hannes
> > 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.
>