Subject: RE: [Geopriv] Geopriv for emergency calls

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 18 Nov 2003 19:33:40 -0500

Right. It has always seemed reasonable to me that one might not want to use
S/MIME in emergency cases. I don't think there needs to be any change in our
existing specifications to accommodate this.

The security concern that has always struck me in these cases is that the
caller should have some capability to authenticate the selective router. Of
course, if we already want TLS to preserve confidentiality of the request,
the certificate presented by the selective router would serve to
authenticate it to the user agent client. So provided there's some text (in
whatever document this will be) about using TLS, I'll be happy.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Tuesday, November 18, 2003 1:21 PM
> To: 'Henning Schulzrinne'; Tschofenig Hannes
> Cc: [email-masked]'
> Subject: RE: [Geopriv] Geopriv for emergency calls
> 
> 
> 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
> 
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:[email-masked]]
> > Sent: Tuesday, November 18, 2003 3:53 PM
> > To: Tschofenig Hannes
> > Cc: 'Rosen, Brian'; [email-masked]'
> > Subject: Re: [Geopriv] Geopriv for emergency calls
> > 
> > 
> > > 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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> > 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Nov 2003 22:55:17 -0500

> whatever document this will be) about using TLS, I'll be happy.

This assumes that the client talks directly to the "SR proxy", so to 
say. However, from Brian's note I read that there would be potentially 
two separate routing decisions made at potentially two separate 
proxies, both of which needed location information. So, I dont see how 
the caller can use TLS to authenticate the SR.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 18 Nov 2003 23:04:57 -0500

> two separate routing decisions made at potentially two separate proxies, 
> both of which needed location information. So, I dont see how the caller 
> can use TLS to authenticate the SR.

There could be more than two routing decisions, depending on how the 
routing data is split up. This is a political decision, not a technical 
one. In NJ, you'd probably have a routing decision in each town, as 
anything else would be violating the sacred principles of fire 
department job protection...

The caller can verify the identity of the first routing proxy, but needs 
to trust its routing decisions afterwards and the chain of proxies. 
There is not much of an alternative: if the first proxy were to lie and 
'accidentally' connect you to 'malpractice.com', you wouldn't be able to 
tell whether this is a legitimate emergency service provider or not, 
even if the host is indeed properly authenticated as being 
malpractice.com. This would probably be a criminal offense 
("impersonating a law enforcement officer" and such), but we shouldn't 
try to solve legal problems by technology.

Henning