Subject: Re: [Sipping] Authentication issues with emergency and other serv ices

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 03 Jan 2003 22:32:56 -0500

Rosen, Brian wrote:
> Well, the basic problem is that you need a global PKI to
> have the signature of the signer verified.  That is
> a hard problem no one has solved.  You might be able to
> provide some traceability using the P-asserted-identity
> header, or the subsequent work Jon Peterson has proposed.
> That would imply that there is a trusted service provider,
> and it wouldn't give you any information about the network
> beyond the "demarc".

Also, as long as identities are cheap, even a client-level PKI doesn't 
really help all that much. We already have SIP services where you can 
get a SIP identity without identifying yourself beyond possibly a 
throw-away email address. You would effectively need a 'bonded' SIP 
address. This might be useful for spam prevention, too, but it's even 
harder here since while one can easily refuse to receive 
un-authenticated email, it's not generally legally possible or desirable 
to refuse unauthenticated emergency calls.

> 
> We have talked about the other side of that problem = 
> authenticating that the caller is talking to a bona fide
> PSAP.  Even that is seen as an impossibly hard problem =
> getting all PSAPs to get a cert signed by a global PSAP
> CA.

To amplify: the typical SSL cert from Thawte or Verisign wouldn't do 
much good here. You need somebody to provide a certificate that 
psap.sometown.ny.us is indeed a PSAP and not the Pseudo-Service Agency 
imPersonator. Things would be somewhat easier if ICANN created another 
restricted top-level domain similar to .museum, but I know of no such plans.

> Brian

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 03 Jan 2003 22:48:14 -0500

One additional comment: even with a global PKI, the caller would need to 
be able to reliably determine the public key of the specific PSAP. There 
doesn't seem to be a way to do this at this point, without adding a lot 
of non-standard signaling exchanges. (The caller would have to place an 
unencrypted call to get back a signed response or use OPTIONS, as 
proposed by Cullen, presumably without any location or other 
privacy-relevant content, and then re-issue the request. This seems 
likely to add multiple seconds to the call setup time. Unless there is a 
recognizable name or some other certificate extension, this doesn't 
really help much.)

---

From: "Dean Willis" <[email-masked]>
Date: Sat, 4 Jan 2003 12:35:24 -0600

> restricted top-level domain similar to .museum, but I know of 

Well, the problem is that you need to be able to trust that the PSAP URL
you've been given is a valid PSAP. That boils down to "so, where did you get
this PSAP URL from?" Once you HAVE a URL, pki can validate that the party
you end up talking to is the rightful holder of that URL.

So let's separate the problem out.

Where does the PSAP URL come from?

Possibilities:

1) Something like DHCP. Well, this pushes the whole trust problem onto DHCP,
doesn't it? Although we SEEM ready to trust DHCP for everything else,
including assignment of DNS servers. This same model generalizes to the
"trusted introducer/configuratio nserver" problem.

2) Something statically configured, perhaps "operator provisioned". This
would mean that the routing infrastructure would have to find you the
"right" PSAP among the many. Potentially, an interesting application of
nearest-anycast, or simply a design problem for an operator network. Might
work in a 3GPP-ish environment (where th P-CSCF can make local diversion
decisions), but how does it help the SIP-phone at my desk?

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 04 Jan 2003 20:00:32 -0500

> you end up talking to is the rightful holder of that URL.

The problem is even worse in that I have no realistic way to determine 
whether I reached the right PSAP, leaving the PKI issues aside. The PSAP 
is determined (in the US) by the MSAG, the Master Street-Address Guide, 
which maps street locations to PSAPs (roughly speaking). Another 
database maps longitude/latitude to jurisdictions. As far as I know, 
this information is not public. (You have to pay a certain database 
company serious money to get it and be authorized.) In addition, PSAPs 
back up each other, so that you may end up at a different PSAP than last 
time you called for quite legitimate reasons.

Thus, under the best of circumstances (with a special credential or a 
restricted domain), you might be able to tell that you have reached *a* 
PSAP among the 5,000 or so in the United States. Whether this is the 
correct PSAP can, at best, be guessed at.

Plus, unlike in the typical case, where you send an INVITE to 
[email-masked] and can expect to get a cert with the principal 
being that address, you'd dial 'sos@somewhere' or 'tel:911' and might 
get back something signed by [email-masked]' (to pick a 
real-life example from 
http://www.admin.co.fayette.ga.us/communications/fayetteco911/).

The SSL-style cert would be useful for the ERC (to use my draft 
terminology). Once it determines the correct PSAP SIP address, it can 
indeed verify that it got connected to it. In practice, this may be 
sufficient as long as you can trust the database.

> "trusted introducer/configuratio nserver" problem.

DHCP is unlikely. My understanding is that jurisdictional boundaries 
change, albeit infrequently, and PSAPs get split and reorganized. Thus, 
you probably don't want to update the DHCP server in each dentist's 
office and law practice when that happens. (It's not even clear how 
you'd notify them all.). Thus, you typically have companies like Intrado 
that provide these databases. (Intrado calls this the CRDB database, see 
http://www.intrado.com/main/offerings/intellivector/wireless/nineoneone/)

> decisions), but how does it help the SIP-phone at my desk?

As above. We have implemented a system that takes a street address, 
converts it to long/lat, feeds it to the database mentioned earlier and 
gets the PSAP. (Clearly, you'd cache the data for your desk SIP phone 
since there's little point in asking the same question again and again.)