idnits 2.17.00 (12 Aug 2021) /tmp/idnits49419/draft-rosen-sipping-cap-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 7, 2009) is 4822 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) == Outdated reference: draft-ietf-geopriv-pdif-lo-profile has been published as RFC 5491 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING B. Rosen 3 Internet-Draft NeuStar, Inc. 4 Intended status: Standards Track H. Schulzrinne 5 Expires: September 8, 2009 Columbia U. 6 H. Tschofenig 7 Nokia Siemens Networks 8 March 7, 2009 10 Session Initiation Protocol (SIP) Event Package for the Common Alerting 11 Protocol (CAP) 12 draft-rosen-sipping-cap-03.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 8, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 The Common Alerting Protocol (CAP) is an XML document format for 51 exchanging emergency alerts and public warnings. This document 52 allows CAP documents to be distributed via the event notification 53 mechanism available with the Session Initiation Protocol (SIP). 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. The 'common-alerting-protocol' Event Package . . . . . . . . . 3 60 3.1. Package Name . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Event Package Parameters . . . . . . . . . . . . . . . . . 4 62 3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 4 63 3.4. Subscription Duration . . . . . . . . . . . . . . . . . . 4 64 3.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 4 65 3.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 5 66 3.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 5 67 3.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 5 68 3.9. Handling of Forked Requests . . . . . . . . . . . . . . . 6 69 3.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 6 70 3.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.13. Use of URIs to Retrieve State . . . . . . . . . . . . . . 6 73 3.14. PUBLISH Bodies . . . . . . . . . . . . . . . . . . . . . . 6 74 3.15. PUBLISH Response Bodies . . . . . . . . . . . . . . . . . 7 75 3.16. Multiple Sources for Event State . . . . . . . . . . . . . 7 76 3.17. Event State Segmentation . . . . . . . . . . . . . . . . . 7 77 3.18. Rate of Publication . . . . . . . . . . . . . . . . . . . 7 78 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 5.1. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 9 81 5.2. Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 5.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 9 83 5.4. Unauthorized Distribution . . . . . . . . . . . . . . . . 10 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 6.1. Registration of the 'common-alerting-protocol' Event 86 Package . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 6.2. Registration of the 88 'application/common-alerting-protocol+xml' MIME type . . . 11 89 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 90 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 93 1. Introduction 95 The Common Alerting Protocol (CAP) [cap] is an XML document format 96 for exchanging emergency alerts and public warnings. This document 97 allows CAP documents to be distributed via the event notification 98 mechanism available with the Session Initiation Protocol (SIP). 100 Additionally, a MIME object is registered to allow CAP documents to 101 be exchanged in other SIP documents. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 3. The 'common-alerting-protocol' Event Package 111 RFC 3265 [RFC3265] defines a SIP extension for subscribing to remote 112 nodes and receiving notifications of changes (events) in their 113 states. It leaves the definition of many aspects of these events to 114 concrete extensions, known as event packages. This document defines 115 such an event package. This section fills in the information 116 required for all event packages by RFC 3265. 118 Additionally, RFC 3903 [RFC3903] defines an extension that allows SIP 119 User Agents to publish event state. According to RFC 3903, any event 120 package intended to be used in conjunction with the SIP PUBLISH 121 method has to include a considerations section. This section also 122 fills the information for all event packages to be used with PUBLISH 123 requests. 125 This document defines a new "common-alerting-protocol" event package. 126 Event Publication Agents (EPA) use PUBLISH requests to inform an 127 Event State Compositor (ESC) of changes in the common-alerting- 128 protocol event package. Acting as a notifier, the ESC notifies 129 subscribers about emergency alerts and public warnings. 131 3.1. Package Name 133 The name of this package is "common-alerting-protocol". As specified 134 in RFC 3265 [RFC3265], this value appears in the Event header field 135 present in SUBSCRIBE and NOTIFY requests. As specified in RFC 3903 136 [RFC3903], this value also appears in the Event header field present 137 in PUBLISH requests. 139 3.2. Event Package Parameters 141 RFC 3265 [RFC3265] allows event packages to define additional 142 parameters carried in the Event header field. This event package, 143 "common-alerting-protocol", does not define additional parameters. 145 3.3. SUBSCRIBE Bodies 147 RFC 3265 [RFC3265] allows a SUBSCRIBE request to contain a body. 148 This document allows the body to contain civic and geodetic location 149 information to be carried. The 2D location shapes listed in 150 [I-D.ietf-geopriv-pdif-lo-profile], e.g., , 151 , , , and a element, defined 152 in [RFC5139], in the body of the message. The recipient of the 153 SUBSCRIBE message SHOULD use this information to restrict the warning 154 messages that are being delivered. [Editor's note: Information about 155 the type of alerts that shall be received may need to be indicated as 156 well.] 158 3.4. Subscription Duration 160 The default expiration time for subscriptions within this package is 161 3600 seconds. As per RFC 3265 [RFC3265], the subscriber MAY specify 162 an alternate expiration in the Expires header field. 164 3.5. NOTIFY Bodies 166 As described in RFC 3265 [RFC3265], the NOTIFY message will contain 167 bodies describing the state of the subscribed resource. This body is 168 in a format listed in the Accept header field of the SUBSCRIBE 169 request, or a package-specific default format if the Accept header 170 field was omitted from the SUBSCRIBE request. 172 In this event package, the body of the notification contains a Common 173 Alerting Protocol (CAP) document, i.e., an XML document. The format 174 of the XML documents used by CAP are described in [cap]. 176 For an initial notify, unlike for other event packages, there is no 177 current initial state, unless there's a pending alert. Hence, 178 returning a NOTIFY with a non-empty body only makes sense if there 179 are indeed active alerts. 181 All subscribers and notifiers of the "common-alerting-protocol" event 182 package MUST support the "application/common-alerting-protocol+xml" 183 data format. The SUBSCRIBE request MAY contain an Accept header 184 field. If no such header field is present, it has a default value of 185 "application/common-alerting-protocol+xml" (assuming that the Event 186 header field contains a value of "common-alerting-protocol"). If the 187 Accept header field is present, it MUST include "application/ 188 common-alerting-protocol+xml". 190 3.6. Notifier Processing of SUBSCRIBE Requests 192 The contents of a CAP document contains public information. Hence, 193 providing CAP documents may not require authorization by subscribers. 195 3.7. Notifier Generation of NOTIFY Requests 197 RFC 3265 [RFC3265] details the formatting and structure of NOTIFY 198 messages. However, packages are mandated to provide detailed 199 information on when to send a NOTIFY, how to compute the state of the 200 resource, how to generate neutral or fake state information, and 201 whether state information is complete or partial. This section 202 describes those details for the common-alerting-protocol event 203 package. 205 A notifier MAY send a NOTIFY at any time. Typically, it will send 206 one when an alert or early warning message is available. The NOTIFY 207 request contains a body containing one or multiple CAP document(s). 208 The times at which the NOTIFY is sent for a particular subscriber, 209 and the contents of the body within that notification, are subject to 210 any rules specified by the authorization policy that governs the 211 subscription. 213 In the case of a pending subscription, when final authorization is 214 determined, a NOTIFY can be sent. If the result of the authorization 215 decision was success, a NOTIFY SHOULD be sent and SHOULD contain a 216 complete CAP document. If the subscription is rejected, a NOTIFY MAY 217 be sent. As described in RFC 3265 [RFC3265], the Subscription-State 218 header field indicates the state of the subscription. 220 The body of the NOTIFY MUST be sent using one of the types listed in 221 the Accept header field in the most recent SUBSCRIBE request, or 222 using the type "application/common-alerting-protocol+xml" if no 223 Accept header field was present. 225 Notifiers will typically act as Event State Compositors (ESC) and 226 thus will learn the 'common-alerting-protocol' event state via 227 PUBLISH requests sent from authorized Event Publication Agents 228 (EPAs). 230 3.8. Subscriber Processing of NOTIFY Requests 232 RFC 3265 [RFC3265] leaves it to event packages to describe the 233 process followed by the subscriber upon receipt of a NOTIFY request, 234 including any logic required to form a coherent resource state. 236 3.9. Handling of Forked Requests 238 RFC 3265 [RFC3265] requires each package to describe handling of 239 forked SUBSCRIBE requests. 241 This specification only allows a single dialog to be constructed as a 242 result of emitting an initial SUBSCRIBE request. 244 3.10. Rate of Notifications 246 RFC 3265 [RFC3265] requires each package to specify the maximum rate 247 at which notifications can be sent. 249 Notifiers SHOULD NOT generate notifications for a single user at a 250 rate of more than once every five seconds. 252 3.11. State Agents 254 RFC 3265 [RFC3265] requires each package to consider the role of 255 state agents in the package and, if they are used, to specify how 256 authentication and authorization are done. This specification allows 257 state agents to be located in the network. 259 3.12. Examples 261 An example is provided in Section 4. 263 3.13. Use of URIs to Retrieve State 265 RFC 3265 [RFC3265] allows packages to use URIs to retrieve large 266 state documents. 268 CAP documents are fairly small. This event package does not provide 269 a mechanism to use URIs to retrieve large state documents. 271 3.14. PUBLISH Bodies 273 RFC 3903 [RFC3903] requires event packages to define the content 274 types expected in PUBLISH requests. 276 In this event package, the body of a PUBLISH request may contain a 277 CAP document. A CAP document describes an emergency alert or an 278 early warning event. 280 All EPAs and ESCs MUST support the "application/ 281 common-alerting-protocol+xml" data format and MAY support other 282 formats. 284 Note that this document does not mandate how CAP documents are made 285 available to the Public Warning System, for example by authorities or 286 similar organizations. The PUBLISH mechanism is one way. 288 3.15. PUBLISH Response Bodies 290 This specification assumes that a PUBLISH also conveys a CAP document 291 that is later sent further on to watchers. 293 3.16. Multiple Sources for Event State 295 RFC 3903 [RFC3903] requires event packages to specify whether 296 multiple sources can contribute to the event state view at the ESC. 298 This event package allows different EPAs to publish CAP documents for 299 a particular user. The concept of composition is not applicable for 300 this application usage. 302 3.17. Event State Segmentation 304 RFC 3903 [RFC3903] defines segments within a state document. Each 305 segment is defined as one of potentially many identifiable sections 306 in the published event state. 308 This event package defines does not differentiate between different 309 segments. 311 3.18. Rate of Publication 313 RFC 3903 [RFC3903] allows event packages to define their own rate of 314 publication. 316 There are no rate-limiting recommendations for common-alerting- 317 protocol publication. Since emergency alerts and early warning 318 events are typically rare there is no periodicity, nor a minimum or 319 maximum rate of publication. 321 4. Examples 323 Here is an example of a CAP document. 325 327 328 KSTO1055887203 329 KSTO@NWS.NOAA.GOV 330 2003-06-17T14:57:00-07:00 331 Actual 332 Alert 333 Public 334 335 Met 336 SEVERE THUNDERSTORM 337 Severe 338 Likely 339 NATIONAL WEATHER SERVICE SACRAMENTO 340 SEVERE THUNDERSTORM WARNING 341 AT 254 PM PDT... 342 NATIONAL WEATHER SERVICE 343 DOPPLER RADAR INDICATED A SEVERE 344 THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY... 345 OR ABOUT 18 MILES SOUTHEAST OF 346 KIRKWOOD... MOVING SOUTHWEST AT 5 MPH. HAIL... 347 INTENSE RAIN AND STRONG DAMAGING WINDS 348 ARE LIKELY WITH THIS STORM 349 TAKE COVER IN A SUBSTANTIAL SHELTER 350 UNTIL THE STORM PASSES 351 BARUFFALDI/JUSKIE 352 353 EXTREME NORTH CENTRAL TUOLUMNE COUNTY 354 IN CALIFORNIA, EXTREME NORTHEASTERN 355 CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN 356 ALPINE COUNTY IN CALIFORNIA 357 38.47,-120.14 38.34,-119.95 38.52,-119.74 358 38.62,-119.89 38.47,-120.14 359 360 361 363 Example for a Severe Thunderstorm Warning 365 5. Security Considerations 367 This section discusses security considerations when using SIP to 368 distribute warning messages using CAP. 370 5.1. Man-in-the-Middle Attacks 372 Threat: 374 The attacker could then conceivably attempt to impersonate the 375 subject (the putative caller) to some SIP-based target entity. 377 Countermeasures: 379 Such an attack is implausible for several reasons. The subject's 380 assertion: 381 * should be signed, thus causing any alterations to break its 382 integrity and make such alterations detectable. 383 * the intended recipients may be listed in the optionally present 384 audience restriction, which is a cleartext field. As such, it 385 would not allow automatic processing but could give the 386 receiving user further hints. 387 * Issuer is represented in the CAP document (in the 388 element). 389 * validity period for the CAP document may be restricted. 391 5.2. Forgery 393 Threat: 395 A malicious user could forge or alter a CAP document in order to 396 convey messages to SIP entities that get immediate attention of 397 users. 399 Countermeasures: 401 To avoid this kind of attack, the entities must assure that proper 402 mechanisms for protecting the CAP documents are employed, e.g., 403 signing the CAP document itself. Section 3.3.2.1 of [cap] 404 specifies the signing of CAP documents. 406 5.3. Replay Attack 408 Threat: 410 Theft of CAP documents described in this document and replay of it 411 at a later time. 413 Countermeasures: 415 A CAP document contains the mandatory , , 416 elements and an optional element. These 417 attributes make the CAP document unique for a specific sender and 418 provide time restrictions. An entity that has received a CAP 419 message already within the indicated timeframe is able to detect a 420 replayed message and, if the content of that message is unchanged, 421 then no additional security vulnerability is created. Nodes that 422 enter the area of a disaster after the initial distribution of 423 warnings have not yet seen the CAP message and, as such, would not 424 be able to distinguish a replay from the initial message being 425 sent around. However, if the threat that lead to the distribution 426 of warning messages is still imminent then there is no reason not 427 to worry about that message. The source distributing the early 428 warning messages is, however, adviced to carefully select a value 429 for the element and it is RECOMMENDED to set this 430 element. 432 5.4. Unauthorized Distribution 434 Threat: 436 When an entity receives a CAP message it has to determine whether 437 the entity distributing the CAP messages is genuine to avoid 438 accepting messages that are injected by malicious users with the 439 potential desire to at least get the users immediate attention. 441 Countermeasures: 443 When receiving a CAP document a couple of verification steps must 444 be performed. First, it needs to be ensured that the message was 445 delivered via a trusted entitiy (such as a trusted SIP proxy) and 446 that the communication channel between the User Agent and it's SIP 447 proxy is properly secured to exclude various attacks at the SIP 448 level. Then, the message contains the that may contain 449 an entity that falls within the white list of the entity receiving 450 the message. Finally, the message is protected by a digital 451 signature and the entity signing the CAP message may again be 452 listed in a white list of the receiving entity and may therefore 453 be trusted. If none of these verification checks lead to a 454 positive indication of a known sender then the CAP document should 455 be treated as suspicious and configuration at the receiving entity 456 may dictate how to process and display CAP documents in such a 457 case. 459 6. IANA Considerations 461 6.1. Registration of the 'common-alerting-protocol' Event Package 463 This specification registers an event package, based on the 464 registration procedures defined in RFC 3265 [RFC3265]. The following 465 is the information required for such a registration: 466 Package Name: common-alerting-protocol 467 Package or Template-Package: This is a package. 468 Published Document: RFC XXX [Replace by the RFC number of this 469 specification]. 470 Person to Contact: Hannes Tschofenig, Hannes.Tschofenig@nsn.com 472 6.2. Registration of the 'application/common-alerting-protocol+xml' 473 MIME type 475 To: ietf-types@iana.org 476 Subject: Registration of MIME media type application/ common- 477 alerting-protocol+xml 478 MIME media type name: application 479 MIME subtype name: common-alerting-protocol+xml 480 Required parameters: (none) 481 Optional parameters: charset; Indicates the character encoding of 482 enclosed XML. Default is UTF-8 [RFC3629]. 483 Encoding considerations: Uses XML, which can employ 8-bit 484 characters, depending on the character encoding used. See RFC 485 3023 [RFC3023], Section 3.2. 486 Security considerations: This content type is designed to carry 487 payloads of the Common Alerting Protocol (CAP). 488 Interoperability considerations: This content type provides a way to 489 convey CAP payloads. 490 Published specification: RFC XXX [Replace by the RFC number of this 491 specification]. 492 Applications which use this media type: Applications that convey 493 alerts and early warnings according to the CAP standard. 494 Additional information: OASIS has published the Common Alerting 495 Protocol at [cap]. 496 Person & email address to contact for further information: Hannes 497 Tschofenig, Hannes.Tschofenig@nsn.com 498 Intended usage: Limited use 499 Author/Change controller: IETF SIPPING working group 500 Other information: This media type is a specialization of 501 application/xml RFC 3023 [RFC3023], and many of the considerations 502 described there also apply to application/ 503 common-alerting-protocol+xml. 505 7. Acknowledgments 507 The authors would like to thank Cullen Jennings for supporting this 508 work. We would also like to thank the participants of the Early 509 Warning Adhoc meeting at IETF#69. 511 8. Normative References 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", March 1997. 516 [cap] Jones, E. and A. Botterell, "Common Alerting Protocol v. 517 1.1", October 2005. 519 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 520 Event Notification", RFC 3265, June 2002. 522 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 523 for Event State Publication", RFC 3903, October 2004. 525 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 526 Types", RFC 3023, January 2001. 528 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 529 10646", STD 63, RFC 3629, November 2003. 531 [I-D.ietf-geopriv-pdif-lo-profile] 532 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 533 PIDF-LO Usage Clarification, Considerations and 534 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 535 (work in progress), November 2008. 537 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 538 Format for Presence Information Data Format Location 539 Object (PIDF-LO)", RFC 5139, February 2008. 541 Authors' Addresses 543 Brian Rosen 544 NeuStar, Inc. 545 470 Conrad Dr 546 Mars, PA 16046 547 US 549 Phone: 550 Email: br@brianrosen.net 551 Henning Schulzrinne 552 Columbia University 553 Department of Computer Science 554 450 Computer Science Building 555 New York, NY 10027 556 US 558 Phone: +1 212 939 7004 559 Email: hgs+ecrit@cs.columbia.edu 560 URI: http://www.cs.columbia.edu 562 Hannes Tschofenig 563 Nokia Siemens Networks 564 Linnoitustie 6 565 Espoo 02600 566 Finland 568 Phone: +358 (50) 4871445 569 Email: Hannes.Tschofenig@gmx.net 570 URI: http://www.tschofenig.priv.at