idnits 2.17.1 draft-ietf-ecrit-data-only-ea-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2010) is 4932 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3265' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'RFC3903' is defined on line 476, 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 (-14) exists of draft-ietf-ecrit-trustworthy-location-01 == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-15 == Outdated reference: A later version (-03) exists of draft-ietf-atoca-requirements-00 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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: April 28, 2011 Columbia U. 6 H. Tschofenig 7 Nokia Siemens Networks 8 October 25, 2010 10 Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using 11 the Session Initiation Protocol (SIP) 12 draft-ietf-ecrit-data-only-ea-01.txt 14 Abstract 16 The Common Alerting Protocol (CAP) is a 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 devices to issue alerts using the 21 CAP document format. 23 Status of this Memo 25 This Internet-Draft is submitted 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). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 28, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Architectural Overview . . . . . . . . . . . . . . . . . . . . 5 60 4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 7 61 4.1. CAP Transport . . . . . . . . . . . . . . . . . . . . . . 7 62 4.2. Profiling of the CAP Document Content . . . . . . . . . . 7 63 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 6.1. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 6.2. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 10 67 6.3. Injecting False Alerts . . . . . . . . . . . . . . . . . . 11 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 7.1. Registration of the 70 'application/common-alerting-protocol+xml' MIME type . . . 12 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 The Common Alerting Protocol (CAP) [cap] is an XML document format 80 for exchanging emergency alerts and public warnings. CAP is mainly 81 used for conveying alerts and warnings between authorities and from 82 authorities to citizen/individuals. This document describes how 83 data-only emergency calls are able to utilize the same CAP document 84 format. 86 Data-only emergency alerts are similar to regular emergency calls in 87 the sense that they require emergency call routing functionality and 88 may even have the same location requirements. On the other hand, the 89 initial communication interaction will not lead to the establishment 90 of a voice or video channel. 92 Based on the deployment experience with non-IP based systems we 93 distinguish between two types of environments, namely (1) data-only 94 emergency alerts that are targeted directly to a recipient 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) and (2) alerts that are targeted to a Service 98 URN as used for regular IP-based emergency calls where the recipient 99 is not known to the originator. We describe these two cases in more 100 detail in Section 3. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 This document utilizes terminology introduced in 109 [I-D.ietf-atoca-requirements]. 111 3. Architectural Overview 113 This section illustrates two envisioned usage modes; targeted and 114 location-based emergency alert routing. Figure 1 shows a deployment 115 variant where a sensor, as the author and originator of the alert, is 116 pre-configured (using techniques outside the scope of this document) 117 to issue an alert to a receiver or an aggregator, a special form of 118 mediator, that processes these messages and performs whatever steps 119 are necessary to appropriately react on the alert. For example, a 120 security firm may use different sensor inputs to dispatch their 121 security staff to a building they protect. 123 +------------+ +------------+ 124 | Sensor | | Aggregator | 125 | | | | 126 +---+--------+ +------+-----+ 127 | | 128 Sensors | 129 trigger | 130 emergency | 131 alert | 132 | MESSAGE with CAP | 133 |----------------------------->| 134 | | 135 | Aggregator 136 | processes 137 | emergency 138 | alert 139 | 200 (OK) | 140 |<-----------------------------| 141 | | 142 | | 144 Figure 1: Targeted Emergency Alert Routing 146 In Figure 2 a scenario is shown whereby the alert is routed using 147 location information and the Service URN. In case the LoST 148 resolution is done at an emergency services routing proxy rather than 149 at the entity issuing the alert since it may not know the address of 150 the receiver. A possible receiver is a PSAP and the recipient of the 151 alert may be call taker. In the generic case, there is very likely 152 no prior relationship between the originator and the receiver, e.g. 153 PSAP. A PSAP, for example, is likely to receive and accept alerts 154 from entities it cannot authorize. This scenario corresponds more to 155 the classical emergency services use case and the description in 156 [I-D.ietf-ecrit-phonebcp] is applicable. 158 +-----------+ +----------+ 159 +--------+ | SIP Proxy | | PSAP as | 160 | Sensor | | as Relay | | Receiver | 161 +---+----+ +---+-------+ +---+------+ 162 | | | 163 Sensors | | 164 trigger | | 165 emergency | | 166 alert | | 167 | | | 168 | | | 169 | MESSAGE with CAP | | 170 | (including Service URN, | 171 | such as urn:service:sos) | 172 |------------------->| | 173 | | | 174 | SIP Proxy performs | 175 | emergency alert | 176 | routing | 177 | | MESSAGE with CAP | 178 | | (including identity info) | 179 | |----------------------------->| 180 | | | 181 | | PSAP 182 | | processes 183 | | emergency 184 | | alert 185 | | 200 (OK) | 186 | |<-----------------------------| 187 | | | 188 | 200 (OK) | | 189 |<-------------------| | 190 | | | 191 | | | 193 Figure 2: Location-Based Emergency Alert Routing 195 4. Protocol Specification 197 4.1. CAP Transport 199 Since alerts structured via CAP require a "push" medium, they SHOULD 200 be sent via the SIP MESSAGE. The MIME type is set to 'application/ 201 common-alerting-protocol+xml'. 203 Alternatively, the SIP PUBLISH mechanism or other SIP messages 204 could be used. However, the usage of SIP MESSAGE is a simple 205 enough approach from an implementation point of view. 207 4.2. Profiling of the CAP Document Content 209 The usage of CAP MUST conform to the specification provided with 210 [cap]. For the usage with SIP the following additional requirements 211 are imposed: 213 sender: When the CAP was created by a SIP-based entity then the 214 element MUST be populated with the SIP URI of that entity. 216 incidents: The element MUST be present whenever there is 217 a possibility that alert information needs to be updated. The 218 initial message will then contain an incident identifier carried 219 in the element. This incident identifier MUST be 220 chosen in such a way that it is unique for a given combination. Note that the element 222 is optional and may not be present. 224 scope: The value of the element MUST be set to "private" as 225 the alert is not meant for public consumption. The 226 element is, however, not used by this specification since the 227 message routing is performed by SIP and the respective address 228 information is already available in the geolocation header. 229 Populating location information twice into different parts of the 230 message can quickly lead to inconsistency. 232 parameter: The element MAY contain additional 233 information specific to the sensor. 235 area: It is RECOMMENDED to omit this element when constructing a 236 message. In case that the CAP message already contained an 237 element then the specified location information MUST be copied 238 into the PIDF-LO structure of the geolocation header element. 240 5. Example 242 Figure 3 shows a CAP document indicating a BURLARY alert issued by a 243 sensor with the identity 'sensor1@domain.com'. The location of the 244 sensor can be obtained from the attached geolocation information 245 provided via the geolocation header contained in the SIP MESSAGE 246 structure. Additionally, the sensor provided some data long with the 247 alert message using proprietary information elements only to be 248 processed by the receiver, a SIP entity acting as an aggregator. 249 This example reflects the description in Figure 1. 251 MESSAGE sip:aggregator@domain.com SIP/2.0 252 Via: SIP/2.0/TCP sensor1.domain.com;branch=z9hG4bK776sgdkse 253 Max-Forwards: 70 254 From: sip:sensor1@domain.com;tag=49583 255 To: sip:aggregator@domain.com 256 Call-ID: asd88asd77a@1.2.3.4 257 Geolocation: 258 ;routing-allowed=yes 259 Supported: geolocation 260 Accept: application/pidf+xml, application/common-alerting-protocol+xml 261 CSeq: 1 MESSAGE 262 Content-Type: multipart/mixed; boundary=boundary1 263 Content-Length: ... 265 --boundary1 267 Content-Type: common-alerting-protocol+xml 268 Content-ID: 269 271 272 S-1 273 sip:sensor1@domain.com 274 2008-11-19T14:57:00-07:00 275 Actual 276 Alert 277 Private 278 abc1234 279 280 Security 281 BURGLARY 282 Expected 283 Likely 284 Moderate 285 SENSOR 1 286 287 SENSOR-DATA-NAMESPACE1 288 123 289 290 291 SENSOR-DATA-NAMESPACE2 292 TRUE 293 294 295 297 --boundary1 299 Content-Type: application/pidf+xml 300 Content-ID: 301 302 307 308 309 310 311 312 313 32.86726 -97.16054 314 315 316 317 318 yes 319 320 2010-07-30T20:00:00Z 321 322 323 802.11 324 325 mac:1234567890ab 326 2010-07-28T20:57:29Z 327 328 329 331 --boundary1-- 333 Figure 3: Example Message conveying an Alert 335 6. Security Considerations 337 This section discusses security considerations when using SIP to make 338 data-only emergency alerts utilizing CAP. Location specific threats 339 are not unique to this document and the discussion in 340 [I-D.ietf-ecrit-trustworthy-location]. 342 6.1. Forgery 344 Threat: 346 An adversary could forge or alter a CAP document to report false 347 emergency alarms. 349 Countermeasures: 351 To avoid this kind of attack, the entities must assure that proper 352 mechanisms for protecting the CAP documents are employed, e.g., 353 signing the CAP document itself. Section 3.3.2.1 of [cap] 354 specifies the signing of CAP documents. This does not protect 355 against a legitimate sensor sending phrank alerts after being 356 compromised. 358 6.2. Replay Attack 360 Threat: 362 An adversary could eavesdrop alerts and reply them at a later 363 time. 365 Countermeasures: 367 A CAP document contains the mandatory , , 368 elements and an optional element. These 369 attributes make the CAP document unique for a specific sender and 370 provide time restrictions. An entity that has received a CAP 371 message already within the indicated timeframe is able to detect a 372 replayed message and, if the content of that message is unchanged, 373 then no additional security vulnerability is created. 374 Additionally, it is RECOMMENDED to make use of SIP security 375 mechanisms, such as SIP Identity [RFC4474], to tie the CAP message 376 to the SIP message. 378 6.3. Injecting False Alerts 380 Threat: 382 When an entity receives a CAP message it has to determine whether 383 the entity distributing the CAP messages is genuine to avoid 384 accepting messages that are injected by adversaries. In scenario 386 Countermeasures: 388 For some types of data-only emergency calls author/originator and 389 the receiver/recipient have a relationship with each other and 390 hence it is possible (using cryptographic techniques) to verify 391 whether a message was indeed issued by an authorized entity. 392 Figure 1 is such an environment. Standard SIP security mechanisms 393 can be re-used for this purpose. For example, identity based 394 access control is a viable approach utilizing the asserted 395 identity of the alert originator using P-Asserted-Identity 396 [RFC3325] or SIP Identity [RFC4474]. 398 There are, however, other types of data-only emergency calls where 399 there is no such relationship between the author/originator and 400 the receiver/recipient. Incoming alerts need to be treated more 401 carefully than multi-media emergency calls that contain additional 402 information, such as audio, to allow a call taker to sort out 403 phrank calls. 405 7. IANA Considerations 407 7.1. Registration of the 'application/common-alerting-protocol+xml' 408 MIME type 410 To: ietf-types@iana.org 412 Subject: Registration of MIME media type application/ common- 413 alerting-protocol+xml 415 MIME media type name: application 417 MIME subtype name: common-alerting-protocol+xml 419 Required parameters: (none) 421 Optional parameters: charset; Indicates the character encoding of 422 enclosed XML. Default is UTF-8 [RFC3629]. 424 Encoding considerations: Uses XML, which can employ 8-bit 425 characters, depending on the character encoding used. See RFC 426 3023 [RFC3023], Section 3.2. 428 Security considerations: This content type is designed to carry 429 payloads of the Common Alerting Protocol (CAP). 431 Interoperability considerations: This content type provides a way to 432 convey CAP payloads. 434 Published specification: RFC XXX [Replace by the RFC number of this 435 specification]. 437 Applications which use this media type: Applications that convey 438 alerts and warnings according to the CAP standard. 440 Additional information: OASIS has published the Common Alerting 441 Protocol at http://www.oasis-open.org/committees/ 442 documents.php&wg_abbrev=emergency 444 Person & email address to contact for further information: Hannes 445 Tschofenig, Hannes.Tschofenig@nsn.com 447 Intended usage: Limited use 449 Author/Change controller: IETF SIPPING working group 451 Other information: This media type is a specialization of 452 application/xml RFC 3023 [RFC3023], and many of the considerations 453 described there also apply to application/ 454 common-alerting-protocol+xml. 456 8. Acknowledgments 458 The authors would like to thank the participants of the Early Warning 459 adhoc meeting at IETF#69 for their feedback. Additionally, we would 460 like to thank the members of the NENA Long Term Direction Working 461 Group for their feedback. 463 9. References 465 9.1. Normative References 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", March 1997. 470 [cap] Jones, E. and A. Botterell, "Common Alerting Protocol v. 471 1.1", October 2005. 473 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 474 Event Notification", RFC 3265, June 2002. 476 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 477 for Event State Publication", RFC 3903, October 2004. 479 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 480 Types", RFC 3023, January 2001. 482 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 483 10646", STD 63, RFC 3629, November 2003. 485 [I-D.ietf-ecrit-trustworthy-location] 486 Tschofenig, H., Schulzrinne, H., and B. Aboba, 487 "Trustworthy Location Information", 488 draft-ietf-ecrit-trustworthy-location-01 (work in 489 progress), October 2010. 491 9.2. Informative References 493 [I-D.ietf-ecrit-phonebcp] 494 Rosen, B. and J. Polk, "Best Current Practice for 495 Communications Services in support of Emergency Calling", 496 draft-ietf-ecrit-phonebcp-15 (work in progress), 497 July 2010. 499 [I-D.ietf-atoca-requirements] 500 Schulzrinne, H., Norreys, S., Rosen, B., and H. 501 Tschofenig, "Requirements, Terminology and Framework for 502 Exigent Communications", draft-ietf-atoca-requirements-00 503 (work in progress), September 2010. 505 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 506 Authenticated Identity Management in the Session 507 Initiation Protocol (SIP)", RFC 4474, August 2006. 509 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 510 Extensions to the Session Initiation Protocol (SIP) for 511 Asserted Identity within Trusted Networks", RFC 3325, 512 November 2002. 514 Authors' Addresses 516 Brian Rosen 517 NeuStar, Inc. 518 470 Conrad Dr 519 Mars, PA 16046 520 US 522 Phone: 523 Email: br@brianrosen.net 525 Henning Schulzrinne 526 Columbia University 527 Department of Computer Science 528 450 Computer Science Building 529 New York, NY 10027 530 US 532 Phone: +1 212 939 7004 533 Email: hgs+ecrit@cs.columbia.edu 534 URI: http://www.cs.columbia.edu 536 Hannes Tschofenig 537 Nokia Siemens Networks 538 Linnoitustie 6 539 Espoo 02600 540 Finland 542 Phone: +358 (50) 4871445 543 Email: Hannes.Tschofenig@gmx.net 544 URI: http://www.tschofenig.priv.at