Subject: Re: [Ecrit] draft-schulzrinne-ecrit-psap-callback-01

From: "John-Luc Bakker" <[email-masked]>
Date: Thu, 3 Dec 2009 13:44:36 -0600

Hello all,

When reading the -01 version of the draft I noticed the analyses of
solutions for "verifying the caller is a PSAP":

   To fulfill the requirements of verifying the caller is a PSAP,
   mechanisms such as those described in RFC 4474 [RFC4474] or in RFC
   3325 [RFC3325] are recommended to be used.  Such an approach would
   mitigate security vulnerabilities, but does not explicitly mark the
   request generated from the PSAP as a request for callback.
   Additional information, such a PSAP whitelist, would have to be
   known.  This is, however, only likely to work in a smaller scale
   rather than world wide.

I will note that I have not been part of some related discussions so
bear with me, please.

I agree that usage of RFC 4474 or RFC 3325 does not indicate the call as
being related to a previous call. These descriptions in these RFCs are
used to verify a caller. They don't seem to address the property of
being able to distinguish between a stand-alone call attempt and a call
attempt related to a previous call. The Reply-To header approach
(discussed earlier in the draft) could perhaps be used to address that
property.

Can somebody clarify the need for the suggested PSAP whitelist? If the
PSAP is identified by means of a service URN, e.g. specified in RFC5031,
then no whitelists seems needed or, if not all emergency service URN are
allowed to bypass e.g. call hold, each white lists would still have a
quite manageable size?

I don't understand the sentence "This is, however, only likely to work
in a smaller scale rather than world wide". Isn't it so that this
solution is applicable where at least RFC 4474 or RFC 3325 are
implemented?

Kind regards,

	John-Luc

--- 
John-Luc Bakker 
Standards Manager 
Research In Motion 
BlackBerry: +1 (908) 463 7321 
Office: +1 (972) 373-1761 
Internal: (820) 63761 
E-mail: [email-masked] 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Sunday, November 01, 2009 7:33 PM
To: [email-masked]
Subject: [Ecrit] draft-schulzrinne-ecrit-psap-callback-01

Hi all, 

please take a look at the updated PSAP callback marking document. With
this version Milan helped us to incorporate more text about the solution
approaches. 

When Marc and I had a discussion with Cullen and Robert about the
milestone updates Cullen indicated that he would like to see an
agreement from the group on the solution approach before the document
can be added to the milestone list.

Furthermore, in the recent 3GPP-IETF conference call we learned that
there is interest from the 3GPP in a solution about PSAP callback
marking. Milan and Keith are keeping an eye on the requirements from the
3GPP side.  

Milan has also written another document that could be interesting to
consider in this specific context, namely
draft-patel-dispatch-cpc-oli-parameter. It provides a solution for an
environment that relies on a chain of trust. 

That's certainly a starting point. But when considering an Internet
context then this security model might not be appropriate and we may
need an additional solutions. This is similar to the PAI vs. SIP
Identity story. 

It would be great to hear your thoughts about this issue and have a look
at the updated document:
http://tools.ietf.org/html/draft-schulzrinne-ecrit-psap-callback-01

Ciao
Hannes
_______________________________________________
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: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 4 Dec 2009 10:30:56 +0200

Hi John-Luc, 

>Hello all,
>
>When reading the -01 version of the draft I noticed the 
>analyses of solutions for "verifying the caller is a PSAP":
>
>I will note that I have not been part of some related 
>discussions so bear with me, please.
>
>I agree that usage of RFC 4474 or RFC 3325 does not indicate 
>the call as being related to a previous call.
>These 
>descriptions in these RFCs are used to verify a caller.

Correct. It is purely about asserting the identity of the party that issued the callback (or any other communication attempt). 

> They 
>don't seem to address the property of being able to 
>distinguish between a stand-alone call attempt and a call 
>attempt related to a previous call.

Completely true. 

>The Reply-To header 
>approach (discussed earlier in the draft) could perhaps be 
>used to address that property.

Yes. This, however, requires that devices along the path say the initial call attempt from the emergency caller to the PSAP and that these devices stored some state. 

This is then more or less what is in Phone BCP already. 

As I wrote in the introduction there are cases where the path taken by the callback is different from the initial call and then no such state would be available.

I was asking the group of how big that problem is and I did not really got any feedback. 

>
>Can somebody clarify the need for the suggested PSAP 
>whitelist? If the PSAP is identified by means of a service 
>URN, e.g. specified in RFC5031, then no whitelists seems 
>needed or, if not all emergency service URN are allowed to 
>bypass e.g. call hold, each white lists would still have a 
>quite manageable size?

The PSAP whitelist is a sort of "naïve" approach. Assume you know the identities of all PSAPs (in a region or in the world), because it is stored somewhere in a registry, then one could create a white list (assuming that the identities provided in the SIP exchange are of any value) and perform the desired treatment. 

When you think of a regional setting then this is indeed something that would work as it is quite likely that VSPs and PSAPs are going to establish some "relationship". 

For the broader Internet sense this would not work but there one can argue that it might not be necessary since most users would come from a small set of VSPs/ASPs anyway. 

Just thinking loud...

>
>I don't understand the sentence "This is, however, only likely 
>to work in a smaller scale rather than world wide". Isn't it 
>so that this solution is applicable where at least RFC 4474 or 
>RFC 3325 are implemented?

These two RFCs only provide the identity assurance but they do not say anything about the authorization decision being performed with these identities afterwards. Often the authorization mechanism is more complex than the plain identity assurance. 

So, in our case the usage of a white list was suggested but this requires that someone creates such a white list and more important keeps it up-to-date. This party has to assure that the entires are actually legitimate PSAPs, i.e. the quality of the registration process is sort of important.

As the number of PSAPs (or in general devices that may issue the communication towards a VSP/ASP) grows the management of the white list becomes non-trivial. Why do I say that? Because we can observe these problems in other areas as well (e.g., Email security, Internet Identity Management, etc.)

Does my response make any sense? 

Ciao
Hannes

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
>please take a look at the updated PSAP callback marking 
>document. With this version Milan helped us to incorporate 
>more text about the solution approaches. 
>
>When Marc and I had a discussion with Cullen and Robert about 
>the milestone updates Cullen indicated that he would like to 
>see an agreement from the group on the solution approach 
>before the document can be added to the milestone list.
>
>Furthermore, in the recent 3GPP-IETF conference call we 
>learned that there is interest from the 3GPP in a solution 
>about PSAP callback marking. Milan and Keith are keeping an 
>eye on the requirements from the 3GPP side.  
>
>Milan has also written another document that could be 
>interesting to consider in this specific context, namely 
>draft-patel-dispatch-cpc-oli-parameter. It provides a solution 
>for an environment that relies on a chain of trust. 
>
>That's certainly a starting point. But when considering an 
>Internet context then this security model might not be 
>appropriate and we may need an additional solutions. This is 
>similar to the PAI vs. SIP Identity story. 
>
>It would be great to hear your thoughts about this issue and 
>have a look at the updated document:
>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: Mon, 07 Dec 2009 10:16:44 -0500

We have looked into whitelist mechanisms for use in the U.S. on the current
emergency call system.  It is very complex.   The problem is that the
outgoing call really is a normal enterprise/local government phone call.  It
thus goes through a myriad of connection arrangements, carriers and
facilities, that are not documented in any way that would allow a whitelist
to be created.  We were looking into establishing list of telephone numbers
that could be used for call backs.  We were willing to have a failsafe
policy of allowing numbers where every call may not be a callback, but at
least some calls from that TN could be a callback.  The complexity of
creating such a database, here at least, is very high.  It would require
identifying the responsible telecom contacts in all 6000+ PSAPs, get them
(all) to cooperate in identifying trunks that the PSAP could place
callbacks, determining the TNs associated with those trunks, and effectively
surveying these people periodically to find out if anything changed.

While we might be able to make the situation somewhat better for our next
generation IP based systems, I think it will be hard to build a whitelist.

Brian

On 12/4/09 3:30 AM, "Tschofenig, Hannes (NSN - FI/Espoo)"
<[email-masked]> wrote:

> Correct. It is purely about asserting the identity of the party that issued
> the callback (or any other communication attempt).
> 
> 
>> They 
> Yes. This, however, requires that devices along the path say the initial call
> attempt from the emergency caller to the PSAP and that these devices stored
> some state. 
> 
> As I wrote in the introduction there are cases where the path taken by the
> callback is different from the initial call and then no such state would be
> available.
> 
> The PSAP whitelist is a sort of "naïve" approach. Assume you know the
> identities of all PSAPs (in a region or in the world), because it is stored
> somewhere in a registry, then one could create a white list (assuming that the
> identities provided in the SIP exchange are of any value) and perform the
> desired treatment.
> 
> When you think of a regional setting then this is indeed something that would
> work as it is quite likely that VSPs and PSAPs are going to establish some
> "relationship". 
> 
> For the broader Internet sense this would not work but there one can argue
> that it might not be necessary since most users would come from a small set of
> VSPs/ASPs anyway.
> 
> Just thinking loud...
> 
>> 
> These two RFCs only provide the identity assurance but they do not say
> anything about the authorization decision being performed with these
> identities afterwards. Often the authorization mechanism is more complex than
> the plain identity assurance.
> 
> So, in our case the usage of a white list was suggested but this requires that
> someone creates such a white list and more important keeps it up-to-date. This
> party has to assure that the entires are actually legitimate PSAPs, i.e. the
> quality of the registration process is sort of important.
> 
> As the number of PSAPs (or in general devices that may issue the communication
> towards a VSP/ASP) grows the management of the white list becomes non-trivial.
> Why do I say that? Because we can observe these problems in other areas as
> well (e.g., Email security, Internet Identity Management, etc.)
>