Common Alerting Protocol (CAP) Based Data-Only Emergency Alerts Using
the Session Initiation Protocol (SIP)
Brian Rosen, Henning Schulzrinne, Hannes Tschofenig (eds), IETF I-D
Members of the IETF Emergency Context Resolution with Internet
Technologies (ECRIT) Working Group have published an initial public
working draft for "Common Alerting Protocol (CAP) Based Data-Only
Emergency Alerts Using the Session Initiation Protocol (SIP)." From
the document Abstract: "The Common Alerting Protocol (CAP) is an XML
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 to utilize the same
CAP document format.
Data-only emergency alerts may be similar to regular emergency calls
in the sense that they have the same emergency call routing and
location requirements; they do, however, not lead to the establishment
of a voice channel. There are, however, data-only emergency alerts
that are targeted directly to a dedicated entity responsible for
evaluating the alerts and for taking the necessary steps, including
triggering an emergency call towards a Public Safety Answering Point
(PSAP).
In the architectural model there are two envisioned usage modes; targeted
and location-based emergency alert routing. 'targeted' has a deployment
variant where a device is pre-configured to issue an alert to an
aggregator that processes these messages and performs whatever steps
are necessary to appropriately react on the alert. In many cases the
device has the address of the aggregator pre-configured and
corresponding security mechanisms are in place to ensure that only
alert from authorized devices are processed... In aanother scenario
the alert is routed using location information and the Service URN.
In this case the device issuing the alert may not know the message
recipient (in case the LoST resolution is done at an emergency services
routing proxy rather than at the end host). In any case, a trust
relationship between the alert-issuing device and the PSAP cannot
be assumed, i.e., the PSAP is likely to receive alerts from entities
it cannot authorize...
Several security considerations are recognized when using SIP to make
data-only emergency alerts utilizing CAP. For example, an adversary could
forge or alter a CAP document to report false emergency alarms. To avoid
this kind of attack, the entities must assure that proper mechanisms for
protecting the CAP documents are employed, e.g., signing the CAP document
itself. Section 3.3.2.1 of the CAL specification describes the signing
of CAP documents. This does not protect against a legitimate sensor
sending phrank alerts after being compromised. Another threat: Theft of
CAP documents described in this document and replay of it at a later
time. Certain attributes make the CAP document unique for a specific
sender and provide time restrictions; it is recommended to make use of
SIP security mechanisms, such as SIP Identity, to tie the CAP message
to the SIP message... When an entity receives a CAP message it has to
determine whether the entity distributing the CAP messages is genuine
to avoid accepting messages that are injected by adversaries. For some
types of data-only emergency calls the entity issuing the alert and
the entity consuming the alert have a relationship with each other and
hence it is possible (using cryptographic authentication ) to verify
whether a message was indeed issued by an authorized entity. There are,
however, other types of data-only emergency calls where there is no
such relationship between the sender and the consumer. In that case
incoming alerts need to be treated more carefully, as the possibilities
to place phrank calls are higher than with regular emergency calls
that at least setup an audio channel...."
http://xml.coverpages.org/draft-ietf-ecrit-data-only-ea-00.txtSee also OASIS Emergency Management TC specifications:
http://xml.coverpages.org/emergencyManagement.html#oasis