idnits 2.17.1 draft-rosen-ecrit-data-only-ea-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2010) is 5162 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3265' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'RFC3903' is defined on line 406, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-14 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT B. Rosen 3 Internet-Draft NeuStar, Inc. 4 Intended status: Experimental H. Schulzrinne 5 Expires: September 7, 2010 Columbia U. 6 H. Tschofenig 7 Nokia Siemens Networks 8 March 6, 2010 10 Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using 11 the Session Initiation Protocol (SIP) 12 draft-rosen-ecrit-data-only-ea-01.txt 14 Abstract 16 The Common Alerting Protocol (CAP) is an XML document format for 17 exchanging emergency alerts and public warnings. CAP is mainly used 18 for conveying alerts and warnings between authorities and from 19 authorities to citizen/individuals. This document describes how 20 data-only emergency alerts allow to utilize the same CAP document 21 format. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 7, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Architectural Overview . . . . . . . . . . . . . . . . . . . . 5 66 4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 7 67 4.1. CAP Transport . . . . . . . . . . . . . . . . . . . . . . 7 68 4.2. Profiling of the CAP Document Content . . . . . . . . . . 7 69 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 6.2. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 9 73 6.3. Injecting False Alerts . . . . . . . . . . . . . . . . . . 9 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 7.1. Registration of the 76 'application/common-alerting-protocol+xml' MIME type . . . 11 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 The Common Alerting Protocol (CAP) [cap] is an XML document format 86 for exchanging emergency alerts and public warnings. CAP is mainly 87 used for conveying alerts and warnings between authorities and from 88 authorities to citizen/individuals. This document describes how 89 data-only emergency calls are able to utilize the same CAP document 90 format. Data-only emergency alerts may be similar to regular 91 emergency calls in the sense that they have the same emergency call 92 routing and location requirements; they do, however, not lead to the 93 establishment of a voice channel. There are, however, data-only 94 emergency alerts that are targeted directly to a dedicated entity 95 responsible for evaluating the alerts and for taking the necessary 96 steps, including triggering an emergency call towards a Public Safety 97 Answering Point (PSAP). 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 3. Architectural Overview 107 This section illustrates two envisioned usage modes; targeted and 108 location-based emergency alert routing. Figure 1 shows a deployment 109 variant where a device is pre-configured (using techniques outside 110 the scope of this document) to issue an alert to an aggregator that 111 processes these messages and performs whatever steps are necessary to 112 appropriately react on the alert. In many cases the device has the 113 address of the aggregator pre-configured and corresponding security 114 mechanisms are in place to ensure that only alert from authorized 115 devices are processed. 117 +--------+ +------------+ 118 | Device | | Aggregator | 119 +---+----+ +------+-----+ 120 | | 121 Sensors | 122 trigger | 123 emergency | 124 alert | 125 | MESSAGE with CAP | 126 |----------------------------->| 127 | | 128 | Aggregator 129 | processes 130 | emergency 131 | alert 132 | 200 (OK) | 133 |<-----------------------------| 134 | | 135 | | 137 Figure 1: Targeted Emergency Alert Routing 139 In Figure 2 a scenario is shown whereby the alert is routed using 140 location information and the Service URN. In this case the device 141 issuing the alert may not know the message recipient (in case the 142 LoST resolution is done at an emergency services routing proxy rather 143 than at the end host). In any case, a trust relationship between the 144 alert-issuing device and the PSAP cannot be assumed, i.e., the PSAP 145 is likely to receive alerts from entities it cannot authorize. This 146 scenario corresponds more to the classical emergency services 147 classical and the description in [I-D.ietf-ecrit-phonebcp] is 148 applicable. 150 +-------+ 151 +--------+ | SIP | +------+ 152 | Device | | Proxy | | PSAP | 153 +---+----+ +---+---+ +---+--+ 154 | | | 155 Sensors | | 156 trigger | | 157 emergency | | 158 alert | | 159 | | | 160 | | | 161 | MESSAGE with CAP | | 162 | (including Service URN, | 163 | such as urn:service:sos) | 164 |------------------->| | 165 | | | 166 | SIP Proxy performs | 167 | emergency alert | 168 | routing | 169 | | MESSAGE with CAP | 170 | | (including identity info) | 171 | |----------------------------->| 172 | | | 173 | | PSAP 174 | | processes 175 | | emergency 176 | | alert 177 | | 200 (OK) | 178 | |<-----------------------------| 179 | | | 180 | 200 (OK) | | 181 |<-------------------| | 182 | | | 183 | | | 185 Figure 2: Location-Based Emergency Alert Routing 187 4. Protocol Specification 189 4.1. CAP Transport 191 Since alerts structured via CAP require a "push" medium, they SHOULD 192 be sent via the SIP MESSAGE. The MIME type is set to 'application/ 193 common-alerting-protocol+xml'. 195 Alternatively, the SIP PUBLISH mechanism or other SIP messages 196 could be used. However, the usage of SIP MESSAGE is a simple 197 enough approach from an implementation point of view. 199 4.2. Profiling of the CAP Document Content 201 The usage of CAP MUST conform to the specification provided with 202 [cap]. For the usage with SIP the following additional requirements 203 are imposed: 205 sender: When the CAP was created by a SIP-based entity then the 206 element MUST be populated with the SIP URI of that entity. 208 incidents: The element MUST be present whenever there is 209 a possibility that alert information needs to be updated. The 210 initial message will then contain an incident identifier carried 211 in the element. This incident identifier MUST be 212 chosen in such a way that it is unique for a given sender / 213 expires combination. 215 scope: The value of the element MUST be set to "private" as 216 the alert is not meant for public consumption. The 217 element is, however, not used by this specification since the 218 message routing is performed by SIP and the respective address 219 information is already available there. Populating address 220 information twice into different parts of the message can quickly 221 lead to inconsistency. 223 parameter: The element MAY contain additional 224 information specific to the sensor. 226 area: For geodetic information the polygon and circle location 227 shapes are available. The ability to conveying a structured 228 format of civic location information is missing and hence civic 229 information is encoded as a text string in the element. 231 5. Example 233 Figure 3 shows a CAP document indicating a BURLARY alert issued by 234 sensor1@example.com indicating that the alert was issued from the 235 civic address NATURAL HISTORY MUSEUM, BURGRING 7, 1010 VIENNA, 236 AUSTRIA. Additionally, the sensor provided some additional data long 237 with the alert message using non-standardized information elements. 239 241 242 S-1 243 sensor1@example.com 244 2008-11-19T14:57:00-07:00 245 Actual 246 Alert 247 Private 248 abc1234 249 250 Security 251 BURGLARY 252 Expected 253 Likely 254 Moderate 255 SENSOR 1 256 257 NATURAL HISTORY MUSEUM, 258 BURGRING 7, 1010 VIENNA, AUSTRIA 259 260 261 262 SENSOR-DATA-NAMESPACE1 263 123 264 265 266 SENSOR-DATA-NAMESPACE2 267 TRUE 268 269 270 272 Figure 3: Example for an alert triggered by a sensor 274 6. Security Considerations 276 This section discusses security considerations when using SIP to make 277 data-only emergency alerts utilizing CAP. 279 6.1. Forgery 281 Threat: 283 An adversary could forge or alter a CAP document to report false 284 emergency alarms. 286 Countermeasures: 288 To avoid this kind of attack, the entities must assure that proper 289 mechanisms for protecting the CAP documents are employed, e.g., 290 signing the CAP document itself. Section 3.3.2.1 of [cap] 291 specifies the signing of CAP documents. This does not protect 292 against a legitimate sensor sending phrank alerts after being 293 compromised. 295 6.2. Replay Attack 297 Threat: 299 Theft of CAP documents described in this document and replay of it 300 at a later time. 302 Countermeasures: 304 A CAP document contains the mandatory , , 305 elements and an optional element. These 306 attributes make the CAP document unique for a specific sender and 307 provide time restrictions. An entity that has received a CAP 308 message already within the indicated timeframe is able to detect a 309 replayed message and, if the content of that message is unchanged, 310 then no additional security vulnerability is created. 311 Additionally, it is RECOMMENDED to make use of SIP security 312 mechanisms, such as SIP Identity, to tie the CAP message to the 313 SIP message. 315 6.3. Injecting False Alerts 316 Threat: 318 When an entity receives a CAP message it has to determine whether 319 the entity distributing the CAP messages is genuine to avoid 320 accepting messages that are injected by adversaries. 322 Countermeasures: 324 For some types of data-only emergency calls the entity issuing the 325 alert and the entity consuming the alert have a relationship with 326 each other and hence it is possible (using cryptographic 327 authentication ) to verify whether a message was indeed issued by 328 an authorized entity. There are, however, other types of data- 329 only emergency calls where there is no such relationship between 330 the sender and the consumer. In that case incoming alerts need to 331 be treated more carefully, as the possibilities to place phrank 332 calls are higher than with regular emergency calls that at least 333 setup an audio channel. 335 7. IANA Considerations 337 7.1. Registration of the 'application/common-alerting-protocol+xml' 338 MIME type 340 To: ietf-types@iana.org 342 Subject: Registration of MIME media type application/ common- 343 alerting-protocol+xml 345 MIME media type name: application 347 MIME subtype name: common-alerting-protocol+xml 349 Required parameters: (none) 351 Optional parameters: charset; Indicates the character encoding of 352 enclosed XML. Default is UTF-8 [RFC3629]. 354 Encoding considerations: Uses XML, which can employ 8-bit 355 characters, depending on the character encoding used. See RFC 356 3023 [RFC3023], Section 3.2. 358 Security considerations: This content type is designed to carry 359 payloads of the Common Alerting Protocol (CAP). 361 Interoperability considerations: This content type provides a way to 362 convey CAP payloads. 364 Published specification: RFC XXX [Replace by the RFC number of this 365 specification]. 367 Applications which use this media type: Applications that convey 368 alerts and warnings according to the CAP standard. 370 Additional information: OASIS has published the Common Alerting 371 Protocol at http://www.oasis-open.org/committees/ 372 documents.php&wg_abbrev=emergency 374 Person & email address to contact for further information: Hannes 375 Tschofenig, Hannes.Tschofenig@nsn.com 377 Intended usage: Limited use 379 Author/Change controller: IETF SIPPING working group 381 Other information: This media type is a specialization of 382 application/xml RFC 3023 [RFC3023], and many of the considerations 383 described there also apply to application/ 384 common-alerting-protocol+xml. 386 8. Acknowledgments 388 The authors would like to thank the participants of the Early Warning 389 adhoc meeting at IETF#69 for their feedback. Additionally, we would 390 like to thank the members of the NENA Long Term Direction Working 391 Group for their feedback. 393 9. References 395 9.1. Normative References 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", March 1997. 400 [cap] Jones, E. and A. Botterell, "Common Alerting Protocol v. 401 1.1", October 2005. 403 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 404 Event Notification", RFC 3265, June 2002. 406 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 407 for Event State Publication", RFC 3903, October 2004. 409 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 410 Types", RFC 3023, January 2001. 412 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 413 10646", STD 63, RFC 3629, November 2003. 415 9.2. Informative References 417 [I-D.ietf-ecrit-phonebcp] 418 Rosen, B. and J. Polk, "Best Current Practice for 419 Communications Services in support of Emergency Calling", 420 draft-ietf-ecrit-phonebcp-14 (work in progress), 421 January 2010. 423 Authors' Addresses 425 Brian Rosen 426 NeuStar, Inc. 427 470 Conrad Dr 428 Mars, PA 16046 429 US 431 Phone: 432 Email: br@brianrosen.net 434 Henning Schulzrinne 435 Columbia University 436 Department of Computer Science 437 450 Computer Science Building 438 New York, NY 10027 439 US 441 Phone: +1 212 939 7004 442 Email: hgs+ecrit@cs.columbia.edu 443 URI: http://www.cs.columbia.edu 445 Hannes Tschofenig 446 Nokia Siemens Networks 447 Linnoitustie 6 448 Espoo 02600 449 Finland 451 Phone: +358 (50) 4871445 452 Email: Hannes.Tschofenig@gmx.net 453 URI: http://www.tschofenig.priv.at