Subject: [Ecrit] PSAP Callback Draft Update

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 14 Oct 2012 14:34:01 +0300

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 14 Oct 2012 14:48:40 -0400

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:
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>