Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Mar 2012 11:57:54 +0100

Hi John-Luc,

I think some of your issues would be solved if the nonce was generated by the registrar.

In that case, it can be provided when the phone you dropped re-registers, and the same value could be given to every phone that may receive the callback (in case it is another phone than the one who made the emergency call).

Regards,

Christer

-----Original Message-----
From: John-Luc Bakker [mailto:[email-masked]] 
Sent: 1. maaliskuuta 2012 0:40
To: Paul Kyzivat; Brian Rosen
Cc: Christer Holmberg; [email-masked]; Nick Russell
Subject: RE: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning

Hi,

I have some further questions regarding the nonce approach.

In this e-mail I consider two types of emergency calls: UA detected and non-UA-detected. A succfully completed non-UA-detected emergency call is less likely to occur, but can happen.

A call back from a PSAP needs to be identified as such in order to allow for special handling to be applied.

If we consider the nonce approach, the UA generating the nonce for a UA detected emergency call can compare the nonce if it gets one back (i.e. if the PSAP makes a call back and the nonce is included). This assumes the UE has "not forgotten" about the nonce (i.e. the device fell out of the user's hand while making the emergency call, dropping both a battery as well as the emergency call prematurely). In case the UA notices the call back header field/parameter, yet fails to match the nonce, the presence of the call back header field/parameter will not cause the UA to handle the call different from a normal call.

This makes sense as in IMS multiple UAs can share the same public user identity. So, assuming no GRUU was used, a UA having registered the same identity may receive the emergency call back. This receiving UA didn't make the emergency call that triggered the callback so it also fails to match the nonce, the presence of the call back header field/parameter will not cause the UA to handle the call different from a normal call. (To prevent the wrong UA from terminating the PSAP call back, a GRUU must be used by the PSAP.)

In case a non-UA-detected emergency call was accepted by the PSAP and the PSAP follows up with a PSAP call back, the PSAP need not have a nonce to include (unless the PSAP has received a nonce while the original emergency call was in progress). At any rate, the PSAP still includes the header/parameter to enable special treatment to be applied by intermediaries. Again, the UA (making the non-UA-detected emergency call) may fail the match, yet the presence of the call back header field/parameter will not cause the UA to handle the call different from a normal call.

The inclusion of the header/parameter parameter already causes special handling by intermediaries, nonce or not. The intermediaries are to "trust" the indication given by the header/parameter. Note that the intermediaries on the path of the PSAP call back are unlikely be the same intermediaries that were on the path of the original emergency call. An intermediary may restart and forget about the nonces. Even if the intermediaries are the same and didn't restart, is it likely that intermediaries will store the nonce for comparison reasons, and how long?

This makes me wonder if we really need the nonce. Above is shown that the absence or presence of the nonce may cause a UA that made an emergency call to fail to recognize the terminating call as an emergency call back from the PSAP. Furthermore, any intermediaries likely also modify the behavior applied to the emergency call back without looking at the nonce.

The protection against abuse of the mechanism should be at the intermediaries (nonce or not). Intermediaries are bound to not like it if the services they provide on behalf of the user are being bypassed. Users also become unhappy when calls that should have been diverted, aren't, due to malicious presence of the header/parameter. 
The UA can protect itself by remembering it did make an emergency call, recently. If the UA has no knowledge of having made an emergency call, it can treat the header/parameter with some skepticism?

Kind regards,

John-Luc

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Thursday, February 23, 2012 12:08 PM
To: Brian Rosen
Cc: John-Luc Bakker; [email-masked]; [email-masked]
Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning

On 2/23/12 12:49 PM, Brian Rosen wrote:
> That's a privacy attack:
>
> I want to know your location, so I force you to send an emergency call.  Then I observe it.
>
> I actually like it, but it has this problem.

Well, the calling UA must recognize the URN in the 3xx as an emergency call URN. And then it does call that address, so the attack is only useful to someone that can observer the subsequent call. But it is an attack to that extent.

It could be mitigated by the UA querying the user before retrying the call as an emergency call. But I suppose some might consider that too much of a delay. OTOH it would only occur when calling a number the phone doesn't *know* to be an emergency number.

There is also the attack of sending a fake configuration to the phone, giving it an emergency dial string that is something the user is likely to call.

	Thanks,
	Paul

> Brian
>
> On Feb 23, 2012, at 12:22 PM, Paul Kyzivat wrote:
>
>> On 2/23/12 9:06 AM, Brian Rosen wrote:
>>> To support emergency calls, the UA pretty much has to know it's an emergency call unless the access network and the origination network are the same entity, or have some kind of relationship.  We have a number of tools that make this possible.  For example, LoST returns the local dial string(s) for emergency calls in the area where the UA is located.  Phonebcp states the UA queries its access network for its own location, then uses that to query LoST for the PSAP URI(s) and local dial string(s).
>>>
>>> In a case where there is a lot of knowledge, a proxy server can add the nonce and the origination network can also arrange for the Contact to be constructed correctly.  IMS actually does have the UE recognizing local emergency dial strings.
>>
>> It always seemed to me that the "best" way to do this would be for the local server that first recognizes this as an emergency call would do a 3xx to urn:sos...  Then the calling device would know that it should treat this as an emergency call.
>>
>> I suppose, in order to cope with devices that wouldn't handle that gracefully, there could be an option that the caller announces support for that would indicate it is ready to do this.
>>
>> 	Thanks,
>> 	Paul
>>
>>> Brian
>>>
>>> On Feb 23, 2012, at 8:09 AM, John-Luc Bakker wrote:
>>>
>>>> Hi,
>>>>
>>>> Was the scenario considered where a UA is unaware it is making an emergency call? For example the user reads the local emergency number (applicable in that region) (I believe the fire brigade in France can be reached by dialing "18") on a sign (then observes an emergency), enters the local number, and the request with that number is sent by the UA.
>>>>
>>>> Does the nonce solution recommend a UA to include the nonce in every SIP request on the off change it turns out to be a request for emergency?
>>>>
>>>> Regards,
>>>>
>>>> John-Luc
>>>> ---
>>>> John-Luc Bakker
>>>> Standards Manager
>>>> Research In Motion Corporation
>>>> Mobile +1 (908) 463 7321
>>>> Office +1 (972) 373-1761
>>>> Internal (820) 63761
>>>> E-mail [email-masked]
>>>>
>>>> Sent from my BlackBerry Torch (9810)
>>>>
>>>> ----- Original Message -----
>>>> From: Christer Holmberg [mailto:[email-masked]]
>>>> Sent: Tuesday, February 21, 2012 09:13 AM
>>>> To: Paul Kyzivat<[email-masked]>; 
>>>> [email-masked]<[email-masked]>
>>>> Subject: Re: [Ecrit] Nonce value -- RE:  PSAP Callback - A New 
>>>> Beginning
>>>>
>>>>
>>>> Hi,
>>>>
>>>>> Ignoring the problem of callback from a PSTN-based psap (which I commented on in earlier message), why isn't the following sufficient:
>>>>>
>>>>> - the caller uses callerprefs to indicate that it doesn't want to
>>>>>   talk to an automaton.
>>>>>
>>>>> - the original emergency caller encodes its contact for the 
>>>>> emergency call with something *it* understands (e.g. a nonce) that it will subsequently treat as granting priority to an incoming call carrying it.
>>>>>
>>>>> In this way nobody but the calling UA need know the nonce 
>>>>> mechanism. It need not be standardized. (And it need not be used at all if the caller is willing to tolerate some priority spit.) The callerprefs will prevent the rest of the infrastructure from diverting the call. This would then be understood to be a mechanism that anybody can use, not just emergency calls.
>>>>>
>>>>> Of course this would require widespread support for callerprefs. But any solution here is going to require widespread support of something.
>>>>
>>>> It is not only the calling UA that needs to know. Intermediaries also need to identify a callback, in order to give special treatment.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>>
>>>> On 2/21/12 8:03 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>>>>> I am NOT talking about replacing GRUU with the feature tag. GRUU 
>>>>>> is still the preferred way of routing to the UA.
>>>>>>
>>>>>> I am just saying that a "side effect" of a feature tag based 
>>>>>> indicator is that it CAN also be used for routing. I am not 
>>>>>> saying that we shall mandate support of feature tag based 
>>>>>> routing. The main purpose of the feature tag is still as indicator.
>>>>>
>>>>> But wouldn't it then be sufficient to have just a SIP header field 
>>>>> set by the PSAP when it sends the callback that says "callback"?
>>>>>
>>>>> Anything else would just be replicating existing functionality.
>>>>>
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>>
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>> -------------------------------------------------------------------
>>>> -- This transmission (including any attachments) may contain 
>>>> confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>
>>>
>>
>
>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Mar 2012 12:20:53 -0500

ISTM that the trouble in figuring this out is lack of clarity about what 
special treatment is supposed to provided in the PSAP callback, or maybe 
this can better be described as what special treatment needs to be 
worked around during the PSAP callback.

Suppose there was *no* special treatment of the callback. Then what 
things might prevent the callback from working?

- an intermediary might divert or reject the call, preventing it from
   reaching the original endpoint, for a variety of reasons:

   * policy controlled by the end user, such as a black/white list or
     unconditional diversion, or time based diversion

   * policy controlled by the intermediary provider, such as
     limitation to one call at a time.

   * a billing limitation such as call block due to unpaid status

   * a resource limitation, such as lack of bandwidth for another call

   * the UA is unreachable

- the UA might reject or divert the call for a variety of reasons

   * policy controlled by the end user, such as disabled alerting,
     unconditional or based on black/white list

   * belief that an emergency call is in progress and other calls should
     be rejected, coupled with inability to recognize the new call as
     a PSAP callback

   * inability or unwillingness to handle concurrent calls coupled
     with belief that the original call (unknown to be an emergency
     call) is still in progress

   * lack of resources to handle the call, such as low battery

The problems at the UA are probably easier to deal with. If the UA just 
remembers that it has made an emergency call recently, and the PSAP 
callback is simply marked, based on the honor system, as an emergency 
callback, then the UA can have policies to deal with this reasonably. 
There is then a risk of "fraud" - of someone impersonating a PSAP 
callback - but they can only work during the period that the UA thinks 
it has made an emergency call. Confusion about whether the existing 
emergency call has dropped or not can be handled via huristics, such as 
assuming the callback is to replace the existing call, or switching to 
the callback but still retaining the state of the prior call and 
allowing the user to switch back to it.

But the UA can only do this if it is aware that it was in an emergency 
call. My prior suggestion for an intermediary to send a 3xx with an sos 
URN when it decides a called number is an emergency call could help with 
that. (Though would need to resolve the issues Brian raised.) Otherwise 
the intermediaries will have to deal with it. But it can still be a 
problem if the UA once knew it was in an emergency call, but then 
forgot. But probably every sip UA today that is likely to be making 
emergency calls will have some non-volatile storage. So I don't think 
that is a problem that needs solving.

To an extent the intermediaries might be able to address this the same 
way by remembering that an emergency call is in progress and adjusting 
policies to take that into account. Use of a nonce, rather than just 
using honor system to identify PSAP callbacks, would potentially 
eliminate some fraud. Whether this is important depends on whether there 
are practical ways to exploit fraud.

If we assume that the intermediaries can know that an emergency call is 
in progress, then its fairly hard to exploit fraud. Unless someone can 
come up with something interesting here maybe that can be considered 
insignificant.

But there has been some concern that the PSAP callback might take a 
different path than the original emergency call and the intermediaries 
on the callback path then might not know that an emergency call is in 
progress. But the nonce is a solution to that only if the intermediaries 
on the callback path can validate the nonce.

One solution to that is for there to be some shared state between the 
intermediaries that handled the original emergency call and those that 
handle the callback. This could be knowledge that an emergency call is 
in progress to a particular UA, or the nonce of such an emergency call.

The only other solution I have heard is some sort of shared secret 
between the PSAP UA making the callback (or an intermediary operating on 
its behalf) and the intermediary making a policy or resource decision 
about the call. AFAIK this is still considered "hard" to deploy in a 
reliable way.

Based on all that, I am inclined to prefer an honor system indication of 
an emergency callback coupled with depending on the intermediaries and 
the called UA remembering that an emergency call is in progress.

That includes expecting the intermediaries that make policy decisions 
consulting some sort of shared state, and UAs that knowingly make 
emergency calls remembering that status in a reliable way.

For those cases when the UA made a call without knowing that it was an 
emergency call, I still think its preferable for the intermediary that 
realizes this to inform the UA (probably via 3xx). If that is 
infeasible, then the intermediary will have to do all it can to expedite 
the PSAP callback at the UA. But there may be little it can do.

	Thanks,
	Paul

On 2/29/12 5:40 PM, John-Luc Bakker wrote:
> Well, the calling UA must recognize the URN in the 3xx as an emergency
> call URN. And then it does call that address, so the attack is only
> useful to someone that can observer the subsequent call. But it is an
> attack to that extent.
>
> It could be mitigated by the UA querying the user before retrying the
> call as an emergency call. But I suppose some might consider that too
> much of a delay. OTOH it would only occur when calling a number the
> phone doesn't *know* to be an emergency number.
>
> There is also the attack of sending a fake configuration to the phone,
> giving it an emergency dial string that is something the user is likely
> to call.
>
> 	Thanks,
> 	Paul
>
>> Brian
>>
>>>>> To: Paul Kyzivat<[email-masked]>; [email-masked]<[email-masked]>
>>>>>> - the original emergency caller encodes its contact for the emergency call with something *it* understands (e.g. a nonce) that it will subsequently treat as granting priority to an incoming
>>>>>> call carrying it.
>>>>>>
>>>>>> In this way nobody but the calling UA need know the nonce mechanism. It need not be standardized. (And it need not be used at all if the caller is willing to tolerate some priority spit.) The
>>>>>> callerprefs will prevent the rest of the infrastructure from diverting the call. This would then be understood to be a mechanism that anybody can use, not just emergency calls.
>>>>>>
>>>>>>> I am NOT talking about replacing GRUU with the feature tag. GRUU is
>>>>>>> still the preferred way of routing to the UA.
>>>>>>>
>>>>>>> indicator is that it CAN also be used for routing. I am not saying
>>>>>>> that we shall mandate support of feature tag based routing. The main
>>>>>>> purpose of the feature tag is still as indicator.
>>>>>>
>>>>>> But wouldn't it then be sufficient to have just a SIP header field set
>>>>>> by the PSAP when it sends the callback that says "callback"?
>>>>>>

---

From: John-Luc Bakker <[email-masked]>
Date: Thu, 1 Mar 2012 21:09:44 +0000

Hi Christer,

To go a along with your scenario where a user e.g. removes the U/SIM from one phone and puts it in another phone after making an emergency call on the first phone. If the registrar creates the NONCE, is the same NONCE made available to all UAs sharing the same public user identity? Is the same nonce returned each time a UE with the same public user identity registers? Or, assuming a deployment where emergency registration is supported, is the same nonce returned each time a UE with the same public user identity performs an emergency registration?

Regards,

	John-Luc

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Thursday, March 01, 2012 4:58 AM
To: John-Luc Bakker; Paul Kyzivat; Brian Rosen
Cc: [email-masked]; Nick Russell
Subject: RE: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning

Hi John-Luc,

Regards,

Christer

-----Original Message-----
From: John-Luc Bakker [mailto:[email-masked]] 
Sent: 1. maaliskuuta 2012 0:40
To: Paul Kyzivat; Brian Rosen
Cc: Christer Holmberg; [email-masked]; Nick Russell
Subject: RE: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning

Hi,

Kind regards,

John-Luc

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Thursday, February 23, 2012 12:08 PM
To: Brian Rosen
Cc: John-Luc Bakker; [email-masked]; [email-masked]
Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning

	Thanks,
	Paul