Subject: Re: [Ecrit] PSAP Callback Draft Update

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 14 Oct 2012 22:55:23 +0300

Hi Paul, 

thanks for the quick feedback. 

Based on our discussions earlier about the PSAP callback there are cases where network intermediaries need to perform this screening. Think about authorization policies and supplementary services (like call forwarding). The earlier sections of the draft describe these scenarios in detail.

The idea of using some timer interval in which the callback must come was raised before and we have that concept in PhoneBCP. The challenge with this idea is that it is difficult to pick a specific time. 

The case that the emergency caller is still having the emergency call when it receives the callback seems rather unlikely. Theoretically, that's possible. Should we indicate that an ongoing call should not be interrupted?

What happens, however, to an ongoing non-emergency call when an incoming callback arrives is indeed a good question. Would you say that the regular call should be preempted or should we better say nothing?
 
For the end device I was arguing in the draft that whitelists are not needed since the screening will have to be done by the VSP. 

Ciao
Hannes

Sent from my ASUS Pad

Paul Kyzivat <[email-masked]> wrote:

>Hi Hannes,
>
>IMO it is not necessary, and not even desirable, the the nodes in the 
>middle of the network to do this level of screening.
>
>Rather, I think it would be better for the phone the make the emergency 
>call to remember that it did, and set up an interval during which it is 
>willing to accept an emergency callback.
>
>* During that interval, if it gets a call marked as a psap callback it 
>should apply whatever special policies it has to such calls. If it is 
>not still engaged in the emergency call it had made, then it might use 
>priority alerting, drop any other call it might be in, etc. (If it *is* 
>still in the original emergency call then it gets complicated. I don't 
>know what it does.)
>
>* If a call marked as a psap callback comes when not in an interval when 
>it is expecting one, it should either treat it as an ordinary call, or 
>reject it altogether.
>
>* The phone could persist the record of the emergency call so that it 
>will still remember after a reboot. If it chooses not to do that, then 
>it can simply assume after a reboot that it might have initiated an 
>emergency call just before the reboot, and so establish an interval for 
>accepting emergency callbacks starting immediately after the reboot. 
>This is relatively safe because to exploit it a caller would need to 
>know when the callee reboots his phone.
>
>This does mean that someone aware that an emergency call has been made 
>could exploit that to get a priority call through to the phone. This 
>seems a minor issue to me. The benefit is that it eliminates all the 
>complications of establishing whitelists for large numbers of otherwise 
>unknown entities, or the need to federate many psaps in order to 
>minimize the size of whitelists.
>
>	Thanks,
>	Paul
>
>On 10/14/12 7:34 AM, Hannes Tschofenig wrote:
>> Hi all,
>>
>> after reaching a conclusion regarding the marking Christer indicated
>> that we are going to provide a draft update before the submission deadline.
>>
>> The security consideration section is currently empty and I have tried
>> to come up with some text. Here is my proposal:
>>
>> --------
>>
>> 5.  Security Considerations
>>
>> 5.1.  Security Threat
>>
>>     The PSAP callback functionality described in this document allows
>>     marked calls to bypass blacklists, ignore call forwarding procedures
>>     and similar features to contact emergency callers and to raise their
>>     attention.  Regarding the latter aspect a callback, if understood by
>>     the SIP UA would allow to override user interface configurations,
>>     such as vibrate-only mode, to alert the caller of the incoming call.
>>
>> 5.2.  Security Requirements
>>
>>     The requirement is to ensure that the mechanisms described in this
>>     document can not be used for malicious purposes, including
>>     telemarketing.
>>
>>     Furthermore, if the newly defined extension is not recognized, not
>>     verified adequately, or not obeyed by SIP intermediaries or SIP
>>     endpoints then it must not lead to a failure of the call handling
>>     procedure.  Such call must be treated like a call that does not have
>>     any marking attached.
>>
>> 5.3.  Security Solution
>>
>>     Figure 6 shows the architecture that utilizes the identity of the
>>     PSAP to decide whether a preferential treatment of callbacks should
>>     be provided.  To make this policy decision the identity of the PSAP
>>     is compared with a whitelist of valid PSAPs available to the SIP
>>     entity.  The identity assurance in SIP can come in different forms,
>>     such as SIP Identity [RFC4474] or with P-Asserted-Identity [RFC3325].
>>     The former technique relies on a cryptographic assurance and the
>>     latter on a chain of trust.  Also the usage of TLS between
>>     neighboring SIP entities may provide useful identity information.
>>
>>
>>                         +----------+
>>                         | List of  |+
>>                         | valid    ||
>>                         | PSAPs    ||
>>                         +----------+|
>>                          +----------+
>>                              *
>>                              * whitelist
>>                              *
>>                              V
>>           Incoming      +----------+    Normal
>>           SIP Msg       | SIP      |+   Treatment
>>          -------------->| Entity   ||======================>
>>           + Identity    |          ||(if not in whitelist)
>>             Info        +----------+|
>>                         +----------+
>>                              ||
>>                              ||
>>                              || Preferential
>>                              || Treatment
>>                              ++========================>
>>                                (if successfully verified)
>>
>>                    Figure 6: Identity-based Authorization
>>
>>     An important aspect from a security point of view is the relationship
>>     between the emergency services network (containing PSAPs) and the VSP
>>     (assuming that the emergency call travels via the VSP and not
>>     directly between the SIP UA and the PSAP).
>>
>>     If there is some form of relationship between the emergency services
>>     operator and the VSP then the identification of a PSAP call back is
>>     less problematic than in the case where the two entities have not
>>     entered in some form of relationship that would allow the VSP to
>>     verify whether the marked callback message indeed came from a
>>     legitimate source.
>>
>>     The establishment of a whitelist with PSAP identities maybe be
>>     operationally complex.  When there is a local relationship between
>>     the VSP/ASP and the PSAP then populating the whitelist is fairly
>>     simple.  For SIP UAs there is no need to maintain a list of PSAPs.
>>     Instead SIP UAs are assumed to trust the correct processing of their
>>     VSP/ASP, i.e., the VSP/ASP processes the PSAP callback marking and,
>>     if it cannot be verified, the PSAP callback marking is removed.  If
>>     it is left untouched then the SIP UA should assume that it has been
>>     verified successfully by the VSP/ASP and it should therefore be
>>     obeyed.
>>
>>
>> --------
>>
>> Feedback welcome!
>>
>> Ciao
>> Hannes
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 14 Oct 2012 16:12:37 -0400

> Based on our discussions earlier about the PSAP callback there are cases where network intermediaries need to perform this screening. Think about authorization policies and supplementary services (…

My feeling is still that the network should get out of the way in these 
cases - just trust the caller and let the callee deal with it.

The one case I know of where that doesn't work is when the callee has 
been barred, say for non-payment. It could be permissive even in that 
case, and just log it as an exception. Some backend system could check 
for abuse and do some blacklisting. But I'll acknowledge that this is 
one case where the approach you propose is attractive. But it concerns 
me that whitelisting PSAPs could be difficult, especially for roaming 
devices that end up talking to a PSAP on the other side of the world 
from their provider's location.

> The idea of using some timer interval in which the callback must come was raised before and we have that concept in PhoneBCP. The challenge with this idea is that it is difficult to pick a specific…

So make it big - an hour, or 24 hours.

> The case that the emergency caller is still having the emergency call when it receives the callback seems rather unlikely. Theoretically, that's possible. Should we indicate that an ongoing call sh…

It seems possible to me. The call may have dropped somewhere along the 
path and the UAC doesn't yet know it.

ISTM this is hard. You don't want to drop the existing call to take the 
new one if there is any possibility that the old one is still 
functional. Perhaps treat it as an extra call coming in and let the user 
switch between them. (But that is worrisome since it is fairly easy to 
lose both with common fat fingering.) Or the two could be mixed. I have 
no good ideas here.

> What happens, however, to an ongoing non-emergency call when an incoming callback arrives is indeed a good question. Would you say that the regular call should be preempted or should we better say…

Similar to above, but with more preference for dropping the existing 
call. Maybe it could be treated like a call waiting case but with 
authomatic switching to the emergency callback - leaving the other one 
up but pending.

> For the end device I was arguing in the draft that whitelists are not needed since the screening will have to be done by the VSP.

Certainly I'm not suggesting whitelists here either.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Oct 2012 09:10:49 -0700

> cases - just trust the caller and let the callee deal with it.

Getting out of the way could be an extraordinary action.

If the entity changes its behaviour as a result of the marking, then
the marking could be exploited.  Limiting the possibility for abuse is
the key.

For an end device, special treatment might be enabled for a period
after an emergency call is made.

A service provider might use whitelisting.  I expect that they will.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Oct 2012 12:32:35 -0400

I've said what I have to say on this.
You that work on this all the time have more insight than I do.

	Thanks,
	Paul

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Oct 2012 14:30:06 +0300

Martin, Paul, 

I am wondering whether my response has helped to clarify and whether I can go ahead and put the text into the draft? 

Ciao
Hannes