RE: [Geopriv] Geopriv for emergency calls

From: Rosen, Brian ^lt;Brian.Rosen@marconi.com>
Date: Tue Nov 18 2003 - 16:21:12 EST

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:hgs@cs.columbia.edu]
> Sent: Tuesday, November 18, 2003 3:53 PM
> To: Tschofenig Hannes
> Cc: 'Rosen, Brian'; 'geopriv@ietf.org'
> 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
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue Nov 18 16:22:21 2003

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