[Ecrit] == PSAP Callback ==

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

Hi all, 

I have added text about PSAP callbacks to the our ECRIT Wiki page
http://trac.tools.ietf.org/wg/ecrit/trac/wiki/WikiStart. I have copied
the text into this mail to simplify the response. YOUR FEEDBACK IS
IMPORTANT. 

http://tools.ietf.org/id/draft-schulzrinne-ecrit-psap-callback-01.txt
defines PSAP callback and illustrates what solution is provided with
existing specifications. It then goes on describing under what
circumstances the existing solution does not work. 

A few design decisions impact the direction of a solution, namely:

1)  Approach 1: Indication that the caller is a PSAP.

2)  Approach 2: Indication that the call is in response to a previous
emergency
    call. 

3)  Approach 3: Indication is that the communication attempt is of
emergency nature. 

The group needs to make a decision about the solution direction. 

We discuss each solution approach in more detail below. 

*** Approach 2: Indication that the call is in response to a previous
emergency
    call. 
	
A variant of approach (2) is already described in Section 13 of
[I-D.ietf-ecrit-framework] and provides the following guidance regarding
callback handling:

      A UA may be able to determine a PSAP call back by examining the
      domain of incoming calls after placing an emergency call and
      comparing that to the domain of the answering PSAP from the
      emergency call.  Any call from the same domain and directed to the
      supplied Contact header or AoR after an emergency call should be
      accepted as a call-back from the PSAP if it occurs within a
      reasonable time after an emergency call was placed.

This approach mimics a stateful packet filtering firewall functionality.
Although this approach is quite coarse grained since any call from the
PSAP's domain is given preferential treatment it is likely to be
practical.

It is possible to reduce the granularity by storing additional
information (such as the username part of the called party rather than
just the domain part). 

*** Approach 1: Indication that the caller is a PSAP.

Approach (1) requires more discussion. Consider the following
approaches:

                 +----------+
                 | List of  |+
                 | valid    ||
                 | PSAP ids ||
                 +----------+|
                  +----------+
                      *
                      * whitelist
                      *
                      V
   Incoming      +----------+    Normal
   SIP Msg       | SIP      |+   Treatment
  -------------->| Entity   ||=============>
   + Identity    |          ||(if not in whitelist)
                 +----------+|
                 +----------+
                      ||
                      ||
                      || Preferential
                      || Treatment
                      ++=============>
                        (in whitelist)

Figure 1: Identity Based Authorization

In Figure 1 an interaction is presented that allows a SIP entity to make
a policy decision whether to bypass installed authorization policies and
thereby providing preferential treatment. To make this decision the
sender's identity is compared with a whitelist of valid PSAPs. The
identity assurances 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. 

The establishment of a whitelist with PSAP identities is operationally
complex and might not easily scale world wide. When there is a local
relationship between the VSP/ASP and the PSAP then populating the
whitelist is far simpler. 

A drawback of the presented solution is that this method does not allow
any mechanism to distinguish different types of calls initiated by
PSAPs. 

An approach that extends the one presented in Figure 1 is outlined in
Figure 2. RFC 4484 illustrated the basic requirements for this
technique.

               +----------+
               | List of  |+
               | trust    ||
               | anchor   ||
               +----------+|
                +----------+
                    *
                    *
                    *
                    V
 Incoming      +----------+    Normal
 SIP Msg       | SIP      |+   Treatment
-------------->| Entity   ||=============>
 + trait       |          ||(no indication
               +----------+| of PSAP)
               +----------+
                    ||
                    ||
                    || Preferential
                    || Treatment
                    ++=============>
                      (indicated as
                       PSAP)

Figure 2: Trait Based Authorization

In a trait-based authorization scenario an incoming SIP message contains
a form of trait, i.e. some form of assertion. The assertion contains an
indication that the sending party has the role of a PSAP (or similar
emergency services entity). The assertion is either cryptographically
protected to enable end-to-end verification or an chain of trust
security model has to be assumed. In Figure 2 we assume an end-to-end
security model where trust anchors are provisioned to ensure the ability
for a SIP entity to verify the received assertion. 

>From a solution point of view various approaches are feasible, such as
SIP SAML (see http://tools.ietf.org/html/draft-ietf-sip-saml-06) or URI
Parameters for indicating the Calling Party's Category and Originating
Line Information (see
http://tools.ietf.org/id/draft-patel-dispatch-cpc-oli-parameter-02.txt).


*** Approach 3: Indication is that the communication attempt is of
emergency nature. 

This approach is a slight modification of the one presented in the
previous section. Instead of indicating that the calling party has the
role of a PSAP it instead indicates the emergency services nature. This
indication cannot be verified by external parties because it heavily
depends on the intention of the call taker itself. Call takers might
make calls that cannot be classified as emergency calls.  It is,
however, possible to combine this marking with the indication of the
PSAP role. A receiving entity might be more inclined to execute
preferential treatment in case (a) there is a close relationship with
the emergency services authorities (e.g. the PSAP identity is listed in
a white list), and (b) an assertion is provided that indicates the
sender's role as a PSAP (or similar emergency services entities).


*** Decisions for the WG to make

a) Do you believe that approach (3) is the correct direction for further
standardization work? 

b) Is it useful to specify the technical capabilities for offering trait
based authorization to simplify decision making with approach (3)? 

Ciao
Hannes