Subject: [Ecrit] [ecrit] #5: Review

From: "ecrit issue tracker" <[email-masked]>
Date: Thu, 21 Apr 2011 22:57:57 -0000

#5: Review

 [BA] Overall, I echo Shida's comments about potential additional
 usage scenarios and have a few additional comments about the
 Security Considerations section.

 Specific comments below:

 Abstract

    The Common Alerting Protocol (CAP) is a document format for
    exchanging emergency alerts and public warnings.  CAP is mainly used
    for conveying alerts and warnings between authorities and from
    authorities to citizen/individuals.  This document describes how
    data-only emergency alerts allow devices to issue alerts using the
    CAP document format.

 [BA] It seems to me that the use of the term "Data-Only" may not be
 appropriate to describe all the potential usage scenarios.   For
 example, might it also not be possible to include CAP within an INVITE?
 Suggestion is that the draft be renamed "CAP Emergency Alerts Using SIP",
 and that the Abstract be changed as follows:

    The Common Alerting Protocol (CAP) is a document format for
    exchanging emergency alerts and public warnings.  CAP is mainly used
    for conveying alerts and warnings between authorities and from
    authorities to citizen/individuals.  This document describes how
    the CAP document format can be used to allow devices to issue
    emergency alerts.

 ----------------------------

    Data-only emergency alerts are similar to regular emergency calls in
    the sense that they require emergency call routing functionality and
    may even have the same location requirements.  On the other hand, the
    initial communication interaction will not lead to the establishment
    of a voice or video channel.

 [BA] There are a number of potential uses for CAP, some of which could not
 be characterized as "Data-only".  For example, CAP could be included in an
 INVITE which also included an SDP offer.  Also an INVITE might be sent
 without CAP and then when a response was received indicating that MESSAGE
 was allowed then a CAP alert could subsequently be sent.  So I wouldn't
 necessarily emphasize the "Data-only" aspect.  Suggested change:

    Eergency alerts containing data are similar to regular emergency calls
 in
    the sense that they require emergency call routing functionality and
    may even have the same location requirements.  On the other hand, the
    communication interaction may occur without establishment
    of a voice or video channel.

 ----------------------------

    Based on the deployment experience with non-IP based systems we
    distinguish between two types of environments, namely (1) data-only
    emergency alerts that are targeted directly to a recipient
    responsible for evaluating the alerts and for taking the necessary
    steps, including triggering an emergency call towards a Public Safety
    Answering Point (PSAP) and (2) alerts that are targeted to a Service
    URN as used for regular IP-based emergency calls where the recipient
    is not known to the originator.  We describe these two cases in more
    detail in Section 3.

 [BA] The term "emergency call" as opposed to "emergency alert" suggests
 that the aggregator could potentially convey the CAP message along with
 establishing non-data channels.  My suggestion is to rewrite as follows:

    Based on the deployment experience with non-IP based systems, two
    major deployment scenarios are envisaged:

    1) Emergency alerts containing only data are targeted to a
       recipient responsible for evaluating the next steps, which
       could include:

          a. Sending an alert containing only data toward a Public
             Safety Answering Point (PSAP);
          b. Establishing an emergency call with a PSAP that could
             include audio/video as well as data

    2)  Emergency alerts targeted to a Service URN used for IP-based
        emergency calls where the recipient is not known to
        the originator.  In this scenario, the alert may contain
        only data (e.g. MESSAGE) or could be included along with
        establishment of an audio/video channel (e.g. INVITE)

 We describe these two cases in more detail in Section 3.

 ----------------------------

 Section 3

 There is a basic issue in scenario described in Figure 2, which
 is handling of failure conditions.

 If we assume that the PSAPs do not deploy new capabilities uniformly,
 then the sender may not know beforehand what capabilities the PSAP
 can support.   For example,  a given PSAP may or may not support MESSAGE,
 may or may not support CAP or PIDF-LO, etc.

 If at all possible, you want to avoid multiple error-terminated
 conversations
 between the sender and receiver, consuming precious time during an
 emergency.

 This is one argument for "silent call" approaches which utilize a
 "known good" mechanism for initiating an emergency call (e.g. an INVITE),
 then follow up with additional messages once the capabilities of
 the responder are known (e.g. from an Allow: header).

 ----------------------------

 Section 4.1

       Alternatively, the SIP PUBLISH mechanism or other SIP messages
       could be used.  However, the usage of SIP MESSAGE is a simple
       enough approach from an implementation point of view.

 [BA] I'm not thrilled with using PUBLISH, so I'd remove that but it
 does occur to me that INVITE would make sense.

 ----------------------------

 Section 5

    Via: SIP/2.0/TCP sensor1.domain.com;branch=z9hG4bK776sgdkse

 [BA] Use of TCP transport makes sense, particularly in scenarios where
 both CAP
 and a PIDF-LO might be included.  You might consider saying something
 about this
 since TCP transport for MESSAGE is not that common today.

 ----------------------------

 Section 6.1

 Does it really make sense to sign the CAP alert when the sender might be a
 sensor
 that may not even by IP-connected, and the signer might be an aggregator
 with a
 different identity from the <sender> or the identity in the From: field of
 the
 SIP message?  If you are going to recommend that, you really need to
 describe
 what if anything the receiver can do to validate the signature.

 ----------------------------

 Section 6.2

       Additionally, it is RECOMMENDED to make use of SIP security
       mechanisms, such as SIP Identity [RFC4474], to tie the CAP message
       to the SIP message.

 [BA] Since the sender of the CAP message and the SIP message can be
 different, RFC 4474 only can guarantee that the message isn't modified;
 it doesn't really "tie them together".  For example, an attacker could
 snoop on a signed CAP message, insert it in a SIP MESSAGE and then
 use RFC 4474, and the sender wouldn't be able to verify that they are
 unrelated though the sender would be accountable for the mis-behavior.

 ----------------------------

 Section 6.3

       For some types of data-only emergency calls author/originator and
       the receiver/recipient have a relationship with each other and
       hence it is possible (using cryptographic techniques) to verify
       whether a message was indeed issued by an authorized entity.
       Figure 1 is such an environment.  Standard SIP security mechanisms
       can be re-used for this purpose.  For example, identity based
       access control is a viable approach utilizing the asserted
       identity of the alert originator using P-Asserted-Identity
       [RFC3325] or SIP Identity [RFC4474].

 [BA] What is the distinction between "forgery" and "Injecting false
 alerts"?
 Verifying the identity of the sender of the SIP message may tell you who
 is accountable for sending the emergency alert, but that isn't the same
 as verifying the authenticity of the alert itself.

 I might suggest that the threat model focus on the following instead:

 1. Prevention of modification of data in transit (e.g. sending MESSAGE
 over TLS)
 2. Verification of the sender identity (Section 6.3)
 3. Signing of alerts (Section 6.1)

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  major                      |   Milestone:  milestone1
Component:  additional-data            |     Version:  1.0       
 Severity:  In WG Last Call            |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/ecrit/trac/ticket/5>
ecrit <http://tools.ietf.org/ecrit/>

---

From: "ecrit issue tracker" <[email-masked]>
Date: Thu, 21 Apr 2011 23:00:14 -0000

#5: Review

Changes (by bernard_aboba@…):

  * component:  additional-data => data-only-ea

Component:  data-only-ea               |     Version:  1.0       

Ticket URL: <https://wiki.tools.ietf.org/wg/ecrit/trac/ticket/5#comment:1>
ecrit <http://tools.ietf.org/ecrit/>