Subject: [Ecrit] PSAP Callback - A New Beginning

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Feb 2012 12:14:23 +0100

Hi,

We need to try to find a way forward with the PSAP callback issue.

There are basically two requirements:

(1). Make sure the PSAP callback call reaches the device that made the associated emergency call
(2). PSAP callback indicator

I don't think there are any major issues regarding (1). The Contact should work, at least for callbacks made not too long after the emergency call. If the callback is made later, when the Contact e.g. is not registered anymore, the PSAP can use the AOR.

(2) is where we've had most discussions.

One question has been whether the UA should provide some nonce value, which is then used in the callback. The UA can check whether the nonce value in the callback is something it has generated - assuming the callback reaches the same UA that made the emergency call.

Intermediaires can use the nonce value (or, the protocol element carrying it) to trigger callback specific procedures, but they will not know whether the actual nonce value was created by the UA.

Regards,

Christer

---

From: Brian Rosen <[email-masked]>
Date: Mon, 20 Feb 2012 08:54:38 -0500

I don't have a problem with a nonce.

We require TLS protection of signaling (because of privacy concerns carrying location and other personal information), which would protect the nonce from misuse.

But, can't the UA and his system construct the contact to contain the nonce if it wants to, with no involvement of the PSAP?

Brian

On Feb 20, 2012, at 6:14 AM, Christer Holmberg wrote:

> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Feb 2012 14:57:35 +0100

Hi, 

> But, can't the UA and his system construct the contact to contain the nonce if it wants to, with no involvement of the PSAP?

Sure. The PSAP only needs to make sure the nonce is sent in the callback INVITE, and if it copies the R-URI from the Contact that should not be a problem.

Regards,

Christer

On Feb 20, 2012, at 6:14 AM, Christer Holmberg wrote:

> (1). Make sure the PSAP callback call reaches the device that made the 
> associated emergency call (2). PSAP callback indicator
> 
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 20 Feb 2012 21:03:33 +0200

Hi Christer, 

there is only one requirement for PSAP callback, namely the ability to
distinguish the PSAP callback (by SIP proxies as well as the SIP UA
itself) from a regular call to avoid having the callback blocked by user
configured authorization policies, or forwarded to an answering machine,
etc. 

The solution has to work with a GRUU and an AoR. If the emergency caller
cannot be reached at the provided GRUU then I expect the PSAP calltaker
user agent software tries the AoR. 

The indicator is a solution - not a requirement. 

Ciao
Hannes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Christer Holmberg
> Sent: Monday, February 20, 2012 1:14 PM
> To: [email-masked]
> Subject: [Ecrit] PSAP Callback - A New Beginning
> 
> 
> 
> Hi,
> 
> I don't think there are any major issues regarding (1). The Contact
> should work, at least for callbacks made not too long after the
> emergency call. If the callback is made later, when the Contact e.g.
is
> not registered anymore, the PSAP can use the AOR.
> 
> 
> One question has been whether the UA should provide some nonce value,
> which is then used in the callback. The UA can check whether the nonce
> value in the callback is something it has generated - assuming the
> callback reaches the same UA that made the emergency call.
> 
> Intermediaires can use the nonce value (or, the protocol element
> carrying it) to trigger callback specific procedures, but they will
not
> know whether the actual nonce value was created by the UA.
> 
> Regards,
> 
> Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Feb 2012 20:34:54 +0100

Hi,

> configured authorization policies, or forwarded to an answering machine,

Correct.

> user agent software tries the AoR.

Yes.

> The indicator is a solution - not a requirement.

Agree. My misstake.

Regards,

Christer

is
not

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 21 Feb 2012 11:18:28 +0200

Hi Christer, Hi Brian,

we had spoken about the Nonce idea in the past (under a different name,
namely the token). 

We also argued that the GRUU could fulfill that purpose.

The problem with that concept was that it only works when the forward
and the reverse path are the same. In our scenarios (at the beginning of
the draft) we argue that this is not the case. 

This brought us back to the PSAP callback indicator (which of course
could take many forms, including the Resource Priority Header, or the
stuff we had put in
http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02

Ciao
Hannes

is
not

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Feb 2012 11:46:51 +0100

Hi Hannes,

When I have been talking about the nonce, I have been talking about the indicator. But, in order to avoid confusion, until we have decided how to implement it, let's talk about the indicator :)

Then, how to implement it?

One alternative would be to use a media feature tag, e.g. +g.sip.emg. The feature tag could also contain a nonce value, created by the UA. For example: +g.sip.emg=6fdxtg4es6

The UA would register the feature tag with its registrar. That way, the home network would be aware of the value.

The UA, when making an emg call, would include the feature tag in the Contact header field of the INVITE.

The PSAP, when making a callback, would include the feature tag in the Accept-Contact header field of the INVITE. In addition to acting as a callback indicator, the feature tag would help in finding the correct UA (e.g. if GRUU is not supported).

The home network can also compare the value with the registered value. And, if they don't match, the home network could reject the request, or don't give callback processing, based on network policy.

(Another alternative would be to define a URI parameter, used in the Contact of the emg call INVITE, and in the R-URI of the callback INVITE. The problem, however, is that the R-URI is overwritten by the home network. If History-Info is supported, it would be put there, but then entities (and the UA) would have to scan through the History-Info list.)

Regards,

Christer

-----Original Message-----
From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:[email-masked]] 
Sent: 21. helmikuuta 2012 11:18
To: Christer Holmberg; [email-masked]
Subject: Nonce value -- RE: [Ecrit] PSAP Callback - A New Beginning

Hi Christer, Hi Brian,

we had spoken about the Nonce idea in the past (under a different name, namely the token). 

The problem with that concept was that it only works when the forward and the reverse path are the same. In our scenarios (at the beginning of the draft) we argue that this is not the case. 

This brought us back to the PSAP callback indicator (which of course could take many forms, including the Resource Priority Header, or the stuff we had put in
http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02

Ciao
Hannes

is
not

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 21 Feb 2012 14:12:05 +0200

Hi Christer, 

thanks for the clarification. 

But wouldn't we essentially re-implement parts of the GRUU functionality
with this specific feature tag? 

I was proposing earlier to use the GRUU (when available) for the purpose
of reaching the calling device. 
Then, in addition there was the actual callback marking, see
http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02#section-4
Finally, there was the security related functionality of which I believe
only the identity-based authorization is practical. Richard had proposed
another mechanism based on LoST, which I found worthwhile to explore as
well. 

Ciao
Hannes

> From: ext Christer Holmberg [mailto:[email-masked]]
> Sent: Tuesday, February 21, 2012 12:47 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
> Subject: RE: Nonce value -- RE: [Ecrit] PSAP Callback - A New
Beginning
> 
> 
> Hi Hannes,
> 
> When I have been talking about the nonce, I have been talking about
the
> indicator. But, in order to avoid confusion, until we have decided how
> to implement it, let's talk about the indicator :)
> 
> One alternative would be to use a media feature tag, e.g. +g.sip.emg.
> The feature tag could also contain a nonce value, created by the UA.
For
> example: +g.sip.emg=6fdxtg4es6
> 
> The UA would register the feature tag with its registrar. That way,
the
> home network would be aware of the value.
> 
> The PSAP, when making a callback, would include the feature tag in the
> Accept-Contact header field of the INVITE. In addition to acting as a
> callback indicator, the feature tag would help in finding the correct
UA
> (e.g. if GRUU is not supported).
> 
> The home network can also compare the value with the registered value.
> And, if they don't match, the home network could reject the request,
or
> don't give callback processing, based on network policy.
> 
> (Another alternative would be to define a URI parameter, used in the
> Contact of the emg call INVITE, and in the R-URI of the callback
INVITE.
> The problem, however, is that the R-URI is overwritten by the home
> network. If History-Info is supported, it would be put there, but then
> entities (and the UA) would have to scan through the History-Info
list.)

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Feb 2012 13:14:39 +0100

Hi, 

> But wouldn't we essentially re-implement parts of the GRUU functionality with this specific feature tag? 

As far as reaching the UA, yes, but the main purpose is to provide the callback indicator.

(Also keep in mind that not every UA support GRUU.)

> I was proposing earlier to use the GRUU (when available) for the purpose of reaching the calling device. 

I am only focusing on the callback marking. But, again, a feature tag may also help in reaching the terminal (in cases where GRUU is not used, AND the home registrar supports feature capabilities).

Regards,

Christer

Finally, there was the security related functionality of which I believe only the identity-based authorization is practical. Richard had proposed another mechanism based on LoST, which I found worthwhile to explore as well. 

Ciao
Hannes

Beginning
the
For
the
UA
or
INVITE.
list.)

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 21 Feb 2012 14:43:19 +0200

Hi Christer, 

we are introducing new functionality to get the PSAP callback
functionality to work and this requires changes to SIP UAs and to
proxies. Existing devices clearly do not support this functionality yet.

So, the argument that GRUU is not supported by certain SIP UAs is
correct but not relevant.

Am I missing something?

Ciao
Hannes

> Sent: Tuesday, February 21, 2012 2:15 PM
Beginning
> > But wouldn't we essentially re-implement parts of the GRUU
> functionality with this specific feature tag?
> 
> 
> I am only focusing on the callback marking. But, again, a feature tag
> may also help in reaching the terminal (in cases where GRUU is not
used,
> AND the home registrar supports feature capabilities).
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> > The UA, when making an emg call, would include the feature tag in
the
> > Contact header field of the INVITE.
> >
> > and the reverse path are the same. In our scenarios (at the
beginning
> of

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Feb 2012 13:59:33 +0100

Hi,

> we are introducing new functionality to get the PSAP callback functionality to work and this requires changes to SIP UAs and to proxies. Existing devices clearly do not support this 
> functionality yet.
>
> So, the argument that GRUU is not supported by certain SIP UAs is correct but not relevant.
>
> Am I missing something?

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.

Regards,

Christer

Beginning
used,
the
beginning

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 21 Feb 2012 15:03:43 +0200

> 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.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 21 Feb 2012 08:03:37 -0500

The problem with any "this is an emergency call back" tags is that anybody can insert them and thus invoke whatever the callback identifier is meant to change in terms of call handling. Thus, only nonce-based mechanisms provide protection against such attacks. With that, the question is which caller-chosen identifiers or nonces can survive the round trip. Once you make the environment sufficiently hostile (SBCs, tel URIs, no changes in UAs, etc.), not much, unfortunately.

Henning

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Feb 2012 09:48:10 -0500

> the draft) we argue that this is not the case.

Its irrelevant if the paths are different. What part of

    When a UAC sends a request that can establish a dialog (such as an
    INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e.,
    the same SIP URI can be used in messages outside this dialog) in the
    Contact header field of the request.

isn't clear? Its certainly possible that a call to the provided contact 
will follow a different path than the call from it. But that is not an 
issue for the ua doing the callback.

The most difficult case seems to be when the PSAP is behind a PSTN 
gateway. In that case the PSAP won't receive the caller's contact 
address - all it can receive is a phone number. That has various sub-cases:

- there is no PSTN phone number assigned to the calling UA

Its hard to make callback from a pstn psap work in this case. A possible 
approach would be for the GW to assign a temporary phone number that 
maps to the caller's Contact. Then callback by the PSAP to this 
temporary phone number will be mapped to the original calling contact. 
If that contact contains an indication that its for an emergency call 
then the call can be given priority, at least by those that understand 
the encoding.

- there is a PSTN phone number that reaches the UA that made
   the emergency call.

This could be treated like the case where the callback to the contact 
doesn't work, with fallback to the caller's AOR (the phone number). The 
limitation is that the callback then looks like a normal call.

It would also be possible to use the temporary phone number approach here.

> http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-02

The problem here is of course one of abuse, unless you have an entirely 
closed network. But because support for emergency calls is so important, 
its likely that the network will be more forgiving than normal, leaving 
it more open to abuse.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Feb 2012 10:09:37 -0500

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.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Feb 2012 16:13:09 +0100

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 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 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.
>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 21 Feb 2012 14:47:52 -0600

At 07:03 AM 2/21/2012, Henning Schulzrinne wrote:
>The problem with any "this is an emergency call back" tags is that 
>anybody can insert them and thus invoke whatever the callback 
>identifier is meant to change in terms of call handling.

and we don't want to give telemarketers any more weapons to get 
through to us ...  :-(

>Thus, only nonce-based mechanisms provide protection against such 
>attacks. With that, the question is which caller-chosen identifiers 
>or nonces can survive the round trip. Once you make the environment 
>sufficiently hostile (SBCs, tel URIs, no changes in UAs, etc.), not 
>much, unfortunately.
>
>Henning
>
> > I am NOT talking about replacing GRUU with the feature tag. GRUU 
> is still the preferred way of routing to the UA.
> >
> that we shall mandate support of feature tag based routing. The 
> main purpose of the feature tag is still as indicator.
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Feb 2012 09:40:42 +0100

Hi,

In many networks the PSAP identity could be asserted, to ensure that the call doesn't come from "anyone".

Regards,

Christer

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: 21. helmikuuta 2012 22:48
To: Henning Schulzrinne; Christer Holmberg
Cc: [email-masked]
Subject: Re: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning

>identifier is meant to change in terms of call handling.

and we don't want to give telemarketers any more weapons to get through to us ...  :-(

>attacks. With that, the question is which caller-chosen identifiers or 
>nonces can survive the round trip. Once you make the environment 
> >> I am only focusing on the callback marking. But, again, a feature 
> >> tag may also help in reaching the terminal (in cases where GRUU is 
> >> not
> > used,
> >> another mechanism based on LoST, which I found worthwhile to 
> >> explore
> > as
> >> well.
> >>
> >> Ciao
> >> Hannes
> >>
> >>
> >>> Accept-Contact header field of the INVITE. In addition to acting 
> >>> as
> > a
> >>> (Another alternative would be to define a URI parameter, used in 
> >>> the Contact of the emg call INVITE, and in the R-URI of the 
> >>> callback
> >> INVITE.
> >>> This brought us back to the PSAP callback indicator (which of 
> >>> course could take many forms, including the Resource Priority 
> >>> Header, or
> > the
> >>> stuff we had put in
> >>>> (1). Make sure the PSAP callback call reaches the device that 
> >>>> made
> >> the
> >>>> value in the callback is something it has generated - assuming 
> >>>> the callback reaches the same UA that made the emergency call.
> >>>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Feb 2012 09:04:39 -0500

Given that there are 6000+ PSAPs in the US, this is likely to be challenging. (We have proposed a mechanism, http://datatracker.ietf.org/doc/draft-ono-dispatch-attribute-validation/, that would make something like that relatively easy, since there's a US PSAP registry maintained by the FCC, but this does require some changes in UA.)

---

From: Brian Rosen <[email-masked]>
Date: Wed, 22 Feb 2012 09:25:04 -0500

The US PSAP registry maintained by the FCC is generally thought of the weakest of the available listings, primarily because:
a) It has more missing PSAPs than the other available registries
b) It doesn't differentiate between primary and secondary PSAPs (and there are more than 6000 primary PSAPs).  Primary PSAPs answer 9-1-1 calls and may dispatch.  Secondary PSAPs only dispatch responders.   A call dispatched by a secondary PSAP is answered initially by a primary PSAP.

There are several other registries that are better.  The NENA registry is better, but the commercial database is probably the best.  None are super accurate.

NENA thinks a PKI for primary PSAPs is practical and is working on the CP for it now.  6000 is not a very big number, and if you do it national to state  to regional hierarchy, you can get good quality credentials.

We need PSAP credentials to allow LIS operators to obscure location for non emergency use.

I think assuming some reasonable credential is acceptable.

Brian

---

From: John-Luc Bakker <[email-masked]>
Date: Thu, 23 Feb 2012 13:09:02 +0000

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, 

Regards,

Christer

---------------------------------------------------------------------
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: Brian Rosen <[email-masked]>
Date: Thu, 23 Feb 2012 09:06:13 -0500

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.  

Brian

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Feb 2012 15:09:50 +0100

Hi, 

> 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. 

Correct. 3GPP has a requirement for that, if the proxy server (P-CSCF) determines the call to be an emergency call.

Regards,

Christer

On Feb 23, 2012, at 8:09 AM, John-Luc Bakker wrote:

>> 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.
>> 
>> 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, 23 Feb 2012 15:36:04 +0000

Hi

So, in deployments where there is a lot of knowledge (e.g. IMS), the P-CSCF could insert the nonce. Hwoever this seems to conflict with what Hannes wrote:

> there is only one requirement for PSAP callback, namely the ability to distinguish the PSAP callback 
> (by SIP proxies as well as the SIP UA itself) from a regular call to avoid having the callback blocked 
> by user configured authorization policies, or forwarded to an answering machine, etc.

If the nonce is inserted by a proxy, can the UA still distinguish the PSAP callback from a regular call?

Regards,

	John-Luc

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Thursday, February 23, 2012 8:10 AM
To: Brian Rosen; John-Luc Bakker
Cc: [email-masked]; [email-masked]
Subject: RE: [Ecrit] Nonce value -- RE: PSAP Callback - A New Beginning

Hi, 

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Feb 2012 12:22:16 -0500

> 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 U…

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

>> To: Paul Kyzivat<[email-masked]>; [email-masked]<[email-masked]>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 23 Feb 2012 12:49:33 -0500

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.

Brian

On Feb 23, 2012, at 12:22 PM, Paul Kyzivat wrote:

> 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
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Feb 2012 13:07:51 -0500

> 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

---

From: John-Luc Bakker <[email-masked]>
Date: Wed, 29 Feb 2012 22:40:22 +0000

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

	Thanks,
	Paul