idnits 2.17.1 draft-barnes-atoca-escape-02.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 : ---------------------------------------------------------------------------- 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 (October 9, 2012) is 4215 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TODO' is mentioned on line 733, but not defined == Unused Reference: 'I-D.ietf-atoca-requirements' is defined on line 788, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ATOCA R. Barnes 3 Internet-Draft A. Chi 4 Intended status: Informational BBN Technologies 5 Expires: April 12, 2013 October 9, 2012 7 Encoding of Secure Common Alert Protocol Entities (ESCAPE) 8 draft-barnes-atoca-escape-02.txt 10 Abstract 12 Recipients of emergency alerts need to be able to verify that an 13 alert they receive was issued by an authorized source. The Common 14 Alerting Protocol (CAP) provides a standard way of encoding alert 15 information. This document describes a security wrapper for Common 16 Alerting Protocol objects to allow alerts to be signed by alert 17 originators. 19 Please send feedback to the atoca@ietf.org mailing list. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 12, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Provisioning Requirements . . . . . . . . . . . . . . . . 4 57 1.2. Open Questions . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. ESCAPE Encoding . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Basic MIME encoding . . . . . . . . . . . . . . . . . . . 6 61 3.2. Alert Tokens . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.3. S/MIME Encapsulation . . . . . . . . . . . . . . . . . . . 7 63 3.4. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 9 65 4.1. Alert Originator (Signer) . . . . . . . . . . . . . . . . 9 66 4.2. Alert Relay (Re-signer) . . . . . . . . . . . . . . . . . 10 67 4.3. Alert Recipient (Verifier) . . . . . . . . . . . . . . . . 10 68 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 77 1. Introduction 79 Emergency alerting is an increasingly important function of 80 telecommunications networks, allowing authorities to distribute 81 warnings of impending danger to large numbers of end users in a short 82 period of time. However, because emergency alerts are such important 83 messages to users, there is much more potential for abuse of alerting 84 than other messaging systems. If an attacker can introduce a false 85 emergency alert, he may be able to cause mass action, such as the 86 evacuation of a building or city. 88 Traditionally, the security of alerting systems has been based mainly 89 on the security of the system by which authorities provide alerts to 90 broadcast points, and on the link-layer security of broadcast media 91 that deliver alerts to end users. For example, alerting systems for 92 cellular networks typically rely on sending alerts over the cellular 93 control plane, so that only the local carrier can deliver alerts to 94 an end device. Alerting via broadcast media such as television or 95 radio is protected by legal limitations on the ability to transmit 96 above certain power thresholds in portions of spectrum used for 97 broadcast media (e.g., television stations). 99 In the context of the Internet, it is impossible to rely on link- 100 layer security because IP runs over many types of link that have no 101 analogous access controls. Indeed, alerts may transit multiple 102 different types of network en route to end devices. For example, if 103 an alert is delivered to a device that routes between cellular, 104 Ethernet, and 802.11 interfaces, the router may need to translate an 105 alert delivered by the cellular control plane into an IP datagram 106 that can be delivered over Ethernet or 802.11. There is thus a need 107 for an end-to-end security mechanism for alerts, so that an endpoint 108 can verify that an alert is authentic even if the alert arrives over 109 an untrusted interface. 111 This document describes ESCAPE, a secure container format for the 112 Common Alerting Protocol (CAP) [CAP]. CAP documents provide 113 information about an emergency alert; ESCAPE-wrapped CAP documents 114 also provide security information that can authenticate the 115 originator of the alert. Using this additional information, end 116 alert recipients can verify that ESCAPE-wrapped alerts were 117 originated by entities they trust, and reject false alerts from 118 untrusted entities. 120 Note that ESCAPE validation is not a complete security solution for 121 alerting. ESCAPE validation will authenticate the originator of an 122 alert; it is up to the device to determine whether the originator is 123 trusted. In general, this will require that devices be provisioned 124 with credentials for trusted entities, either via manual provisioning 125 (e.g., static keys in device firmware) or by some dynamic 126 provisioning protocol. 128 Likewise, ESCAPE validation only proves that an alert came from an 129 authorized originator, not whether the alert is relevant to the 130 recipient in a more general sense. For example, the recipient may be 131 outside the target area of the alert (as described by the "" 132 element of the CAP document). Alert applicability involves more than 133 authenticity: it includes location, jurisdiction, and possibly other 134 locale-specific factors. Other specifications may make additional 135 requirements on the contents of CAP documents, or require endpoints 136 to make checks on encoded CAP document beyond the basic validity 137 check required by this document. 139 1.1. Provisioning Requirements 141 For purposes of this document, we assume that potential recipients of 142 ESCAPE objects can be provisioned with two types of credentials: 143 public keys and "alert token hashes". A public key for an authority 144 is used to validate digital signatures by that authority. Alert 145 tokens provide a faster rough authentication. 147 An alert token is a single-use binary string that is used as a fast 148 authentication check, according to the process described in 149 [RFC2289]. Clients are provisioned with a cryptographic hash that 150 was produced by multiple iterations of a hash function against a 151 secret binary string. Although the final hash is published to 152 recipients through some provisioning process, the sequence of 153 preimages, including the original secret string, are known only to an 154 authorized server. These preimages are used in reverse order as the 155 alert tokens. On receiving an alert token, a client hashes it one or 156 more times to verify that it is indeed a preimage of the publicly 157 provisioned hash, or optimally, the immediate preimage of the latest 158 alert token. (Thus, alongside alert tokens, the provisioning system 159 must specify the hash function used to verify the alert token as well 160 as an iteration limit.) The detailed steps for verifying an ESCAPE 161 object using a collection of provisioned public keys and alert tokens 162 is described in Section 4.3. 164 The high-level operation of an ESCAPE-based alerting system can be 165 summarized as follows: 167 1. Endpoints are provisioned with public keys and/or alert token 168 hashes for authorities. 170 2. When an authority wishes to generate an alert, it includes an 171 alert token and signs it using its private key (Section 4.1) 173 3. The alert is distributed to one or more endpoints. 175 4. Along the way, an intermediary may add a signature to the object 176 (Section 4.2). 178 5. When the alert arrives at an endpoint, the endpoint validates the 179 signature and alert token (Section 4.3). If both are valid, it 180 renders the alert to the user. 182 This document defines procedures for generating, re-signing, and 183 verifying alerts (steps 2, 4, and 5 above). The mechanisms used for 184 provisioning trusted credentials (step 1) and for the actual delivery 185 of alerts (step 3) are beyond the scope of this document. 187 1.2. Open Questions 189 Should we always apply GZIP to the entire encoded message? Pro: 190 Slightly smaller message size. Con: Will need to require GZIP for 191 all messages or add content transfer encoding indication. 193 Should we allow DER-encoded CAP as well as XML-encoded CAP? Pro: 194 Smaller message size. Con: Clients need to support two encodings, 195 although MIME content indication allows simple switching. 197 Should we constrain crypto algorithms? Pro: Marginally simpler 198 implementation. Con: Need to maintain a list of supported 199 algorithms. Could also do this in another document. 201 Should we require a public-key signature, or allow reliance on token 202 checks alone? Pro: Enables cases with no public-key operations. 203 Con: Risk of replay attacks using old tokens. 205 Should we move the Alert-Token field from the inner (signed) MIME 206 entity to the outer (unsigned) MIME entity? Pro: Allows relays to 207 add tokens. Con: Allows relays and attackers to remove or change 208 tokens. 210 Should we use JOSE instead of S/MIME? Pro: Simpler to implement; 211 might make it easier to have multiple, detached signatures with their 212 own alert tokens. Con: Less mature, fewer libraries. 214 2. Definitions 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 218 document are to be interpreted as described in RFC 2119 [RFC2119]. 220 3. ESCAPE Encoding 222 The ESCAPE format encapsulates a CAP document as an S/MIME object 223 [RFC5751]. First, the CAP document is encoded as a MIME entity 224 [RFC2045], then the MIME entity is signed using S/MIME. 226 3.1. Basic MIME encoding 228 CAP XML documents have MIME type "application/cap+xml". An alert 229 originator may choose to apply the gzip compression scheme to the 230 alert before sending it. If the alert is compressed, the originator 231 must encode the compressed alert using the base64 encoding scheme 232 before transmitting it [RFC1952][RFC4648]. A CAP MIME body thus has 233 the following properties: 235 o A "Content-Type" header field MUST be present, with the single 236 value "application/cap+xml". 238 o A "Content-Encoding" header field MAY be present. If present, it 239 MUST have the value "gzip", and there MUST be a "Content-Transfer- 240 Encoding" header with the value "base64". 242 o The body of the MIME entity MUST be a CAP document, either 243 directly, or processed through the gzip and base64 encodings. 245 3.2. Alert Tokens 247 ESCAPE introduces a new MIME header, Alert-Token, which provides a 248 rough form of authentication. If alert recipients are configured 249 with an algorithm for checking the validity of a token, along with 250 the appropriate authentication material, the recipient of an alert 251 message can check the validity of the value in the Alert-Token field 252 before performing full S/MIME validation on the ESCAPE object. The 253 Alert-Token field contains a single opaque binary string, encoded in 254 base64. The ABNF syntax ([RFC5234]) for the field is as follows, 255 where "base64" is as defined in RFC 4566 [RFC4566]. (Here we also 256 follow the usual conventions with regard to whitespace in MIME 257 headers.) 259 Alert-Token = "Alert-Token" ":" base64 261 An ESCAPE MIME entity MAY contain one or more Alert-Token header 262 fields. Any header fields other than "Content-Type", "Content- 263 Encoding", "Content-Transfer-Encoding", and "Alert-Token" MAY be 264 ignored by alert recipients. 266 The Alert-Token authentication system implements an iterative hash- 267 preimage scheme based on the same technique used by Lamport's One- 268 Time Password system [RFC2289]. Such a scheme can provide rough 269 authentication when the communication channel is adequately 270 integrity-protected (e.g., by the signature on the ESCAPE object). 272 The Alert Originator, such as a government authority, first generates 273 a sequence of one-time-use alert tokens, which are initially kept 274 secret, known only to the Alert Originator. To do so, the Alert 275 Originator chooses an iteration limit (n), and computes a hash chain 276 starting from a secret binary string (s), and iteratively applies a 277 cryptographic hash function (h) up to n times: 279 s, h(s), h^2(s), ... , h^(n-1)(s), h^n(s) 281 The final hash, h^n(s), is publicly provisioned (out of band) to the 282 clients, along with the iteration limit, n. All previous elements of 283 the sequence are initially kept secret by the authority for use as 284 alert tokens. Note that once a token in the above sequence is 285 public, so are all subsequent tokens. Each independent authority 286 computes its own sequence of tokens, so each authority provisions one 287 ordered pair (final_hash, iteration_limit) to the recipients. 289 When sending an emergency alert, the Alert Originator inserts an 290 alert token in an Alert-Token header in the ESCAPE message and 291 transmits the alert. The value of this token will generally be the 292 immediate hash-preimage of the previous alert token. An Alert 293 Recipient device receiving the message verifies the Alert-Token by 294 iteratively computing the hash value of the alert token until it 295 matches the most recent public hash, or until the iteration limit is 296 reached. If a match is found, then the alert token is considered 297 valid. Otherwise, the alert token is considered invalid. 299 To diminish the chances of replay, when the Alert Recipient 300 encounters a valid Alert-Token, it MUST update its record of the 301 "most recent public hash" and decrement the iteration limit. Replays 302 of the same token MUST be rejected. 304 3.3. S/MIME Encapsulation 306 After a CAP message has been encoded into a MIME entity, an S/MIME 307 signature is applied, following the S/MIME procedures for 308 constructing a signed message of type "multipart/signed" (Section 3.4 309 of RFC 5751 [RFC5751]). The following constraints apply to the 310 S/MIME encoding used in ESCAPE messages. 312 o The ESCAPE message MUST have type "multipart/signed". 314 o If the ESCAPE message contains header fields other than "Content- 315 Type", then they MAY be ignored. 317 o The S/MIME body part SHOULD NOT include certificates for signers, 318 in order to minimize message size. 320 o The S/MIME body part SHOULD identify signers by subject key 321 identifier (SKI) rather than by subject name, in order to allow 322 for both certified and uncertified public keys [RFC5652]. If the 323 SKI is used to identify signers, then it MUST be equal to the 160- 324 bit SHA-1 hash of the value of the BIT STRING subjectPublicKey as 325 specified in Section 4.2.1.2 of [RFC5280]. 327 Except the constraints above, software to verify ESCAPE alerts MUST 328 include full S/MIME support, including all defined cryptographic 329 algorithms [RFC3370][RFC5754]. Implementations MAY include 330 additional algorithms, but alert signers SHOULD NOT sign alerts with 331 non-standard algorithms, since some recipients may not be able to 332 process them. 334 3.4. Validity 336 An ESCAPE object is valid if and only if all of the following 337 conditions are true: 339 o If the verifying entity is configured with a valid alert token 340 hash for the cognizant Alert Originator, then there must be at 341 least one Alert-Token header field containing a valid token. 343 o If the verifying entity is configured with trusted public keys, 344 then the S/MIME signature on the object must be valid, and must be 345 verified using a trusted public key. 347 An entity verifying an ESCAPE object MUST verify both of these 348 criteria, but MAY check them in either order and omit further checks 349 after the object fails one check. In particular, performing the 350 token check before decoding and verifying the CMS signature may avoid 351 the work of signature verification. 353 Note that the alert token mechanism is a much weaker form of 354 authentication than a public-key signature. For example, a malicious 355 actor that receives an alert token could use it to send bogus alerts 356 to entities that had not yet received it. An alert recipient that is 357 not provisioned with trusted public keys should thus treat alerts 358 verified only by an alert token as suspect (e.g., by providing 359 warnings in a user interface). A verifying entity SHOULD NOT accept 360 ESCAPE objects if it is configured with neither trusted public keys 361 nor valid tokens. 363 4. Processing Rules 365 There are three main phases in the life-cycle of an ESCAPE object. 366 First, it is created and signed by an alert originator. Second, it 367 may pass through an alert relay that adds a signature under its key. 368 Finally, it is received and verified by an end recipient. This 369 section describes the steps that each type of entity follows to sign, 370 re-sign or verify an ESCAPE object. 372 4.1. Alert Originator (Signer) 374 Inputs: 376 o CAP document 378 o Private key for signing, and corresponding subject key identifier 380 o gzip flag 382 o Token hash sequence (possibly empty), with the index of the most 383 recently used token hash 385 Processing steps: 387 1. Encode the CAP document as a MIME entity. 389 A. Add a "Content-Type" header field with value "application/ 390 cap+xml". 392 B. If the gzip flag is set, add a "Content-Encoding" header 393 field with value "gzip" and a "Content-Transfer-Encoding" 394 header field with value "base64". 396 C. Add an "Alert-Token" header field and insert a previously 397 unused alert token, from earlier in the hash sequence than 398 the earliest used token. Update the "earliest used token" 399 index. 401 D. If the gzip flag is set, gzip the CAP document, then gzip and 402 base64-encode the CAP document and set it as the message 403 body. 405 E. If the gzip flag is not set, set the CAP document as the 406 message body. 408 2. Compute the signature over the MIME entity using the signing key 409 and create a CMS SignedData structure that identifies the signer 410 using the corresponding subject key ID. 412 3. Combine the CAP MIME entity and the computed CMS SignedData 413 structure into a "multipart/signed" S/MIME object. 415 Output: ESCAPE message 417 4.2. Alert Relay (Re-signer) 419 Inputs: 421 o ESCAPE object 423 o Private key for signing and corresponding subject key ID 425 Processing steps: 427 1. Extract the CAP MIME entity and CMS SignedData object from the 428 ESCAPE message. 430 2. Compute the signature over the CAP MIME entity using the signing 431 key. 433 3. Append the signature value and subject key ID to the CMS 434 SignedData object as a new SignerInfo. 436 4. Combine the CAP MIME entity and the computed CMS SignedData 437 structure into a "multipart/signed" S/MIME object. 439 Output: ESCAPE message 441 4.3. Alert Recipient (Verifier) 443 Inputs: 445 o ESCAPE object 447 o Set of trusted public keys (possibly empty) 449 o Set of trusted alert token hashes, with corresponding iteration 450 limits (possibly empty) 452 Processing steps: 454 1. Extract the CAP MIME entity and the CMS SignedData object from 455 the ESCAPE message. 457 2. Check that the MIME headers for the CAP MIME entity have the 458 correct values. 460 * Content-Type must be "application/cap+xml" 462 * Content-Encoding must be "gzip" or absent 464 * Content-Transfer-Encoding must be present and equal to 465 "base64" if Content-Encoding is present, otherwise absent. 467 If any of these headers are invalid, then return the CAP message 468 is malformed. Return FALSE. 470 3. Extract the CAP entity body. If the Content-Encoding is "gzip", 471 then base64-decode and un-gzip the CAP entity body. 473 4. If the set of trusted alert token hashes includes a token hash 474 for the cognizant Alert Originator, then verify that the Alert- 475 Token values in the CAP MIME entity is a valid token, using the 476 algorithm described in Section 3.2. If no valid alert token is 477 provided, then return FALSE. 479 5. If the set of trusted public keys is non-empty, then verify that 480 at least one of the SignerInfos within the CMS SignedData object 481 contains a valid signature under a trusted key. If no valid, 482 trusted signature is found, then return FALSE. 484 6. Return TRUE. 486 Output: Verification status 488 5. Examples 490 Consider the following CAP message: 492 493 494 43b080713727 495 hsas@dhs.gov 496 2003-04-02T14:39:01-05:00 497 Actual 498 Alert 499 Public 500 501 Security 502 Homeland Security Advisory System Update 503 Immediate 504 Severe 505 Likely 506 U.S. Government, 507 Department of Homeland Security 508 Homeland Security Sets Code ORANGE 509 The Department of Homeland Security has 510 elevated the Homeland Security Advisory System threat level 511 to ORANGE / High in response to intelligence which may 512 indicate a heightened threat of terrorism. 513 A High Condition is declared when there is a 514 high risk of terrorist attacks. In addition to the 515 Protective Measures taken in the previous Threat Conditions, 516 Federal departments and agencies should consider agency- 517 specific Protective Measures in accordance with their 518 existing plans. 519 http://www.dhs.gov/dhspublic/display?theme=29 520 521 HSAS 522 ORANGE 523 524 525 Image file (GIF) 526 http://www.dhs.gov/dhspublic/getAdvisoryImage 527 528 529 U.S. nationwide and interests worldwide 530 531 532 534 Suppose an alert signer has the following RSA key pair, encoded as a 535 PEM-encoded private key and self-signed certificate [RFC1421]: 537 -----BEGIN PRIVATE KEY----- 538 MIICeAIBADANBgkqhkiG9w0BAQEFAASCAmIwggJeAgEAAoGBAMqjkUYoHtH+uLPo 539 w3FNAlpHyT5BG0KWjN6hG7LUgh2GP+c2wmyavn9+ShwEe1CG9qgwa1apqNl/7BTY 540 UoRTCsSMlg43N+3X5OJSVHSALhR/IDcItf32jLUUD88lgKUoXI145GpeXRG3OARx 541 vA0ONhvC6MdSB0gW8jx/7Vz6q+mPAgMBAAECgYB2sqtlMhkjnxaoY/8f/iETqxsp 542 uU9ziOaJfkvQTATPsJT8JiprHZXa7qoQkVt+hyAy0vH9OLJsfS9X4oMrec1C22Jm 543 1EUqOqg+CXLye0OPSYckZukEPAt3EyQNBg4BIZFWC4ouKVcy0UECuL5X6oZ5Z5us 544 nMJ0wHI8n6ghiY620QJBAPFm6sNOOZqs0jFutbHWm5eQ7vbNynGYcm4S2v7Esnyn 545 GKy2iMf8MMiJjqmJiYQ47wn/Rm5rljNu/eTPNopcKhkCQQDW5JGsV6piWLN4fvg9 546 tpv0OG/mqJUBwjEejGg0LzupQiHociEg+cm+IPP61NX/MXoQXQIoFKcc6nXXq4rt 547 +PXnAkEAiurg2nefqqUdaJj/MlH/w98BxUFz6J8D6tgq8kWbOSSnjGyWlg9Iu359 548 fI7Ldi2VUbl3fH+pNfv/W7bq+gBDsQJBAMKNsa18uQ/NCr9/BLSqzUswhW8pFa6/ 549 58SmjfkhAjzdWOGf4op+W749C2b+prgiTUbfTgKHoDy3sPUPo/qLueUCQQCdIdRB 550 3SrfM1gedy2h20RiFu6Ew1GCFSK2DUv60BcZJmbazVCNFQq8wBtHuqHew/7hxmtA 551 DtxHTLote/VHyOj7 552 -----END PRIVATE KEY----- 554 -----BEGIN CERTIFICATE----- 555 MIICKTCCAZKgAwIBAgIJAIGuauj9u0i0MA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV 556 BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX 557 aWRnaXRzIFB0eSBMdGQwHhcNMTExMDAzMjEzNDIzWhcNMTIxMDAyMjEzNDIzWjBF 558 MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50 559 ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB 560 gQDKo5FGKB7R/riz6MNxTQJaR8k+QRtClozeoRuy1IIdhj/nNsJsmr5/fkocBHtQ 561 hvaoMGtWqajZf+wU2FKEUwrEjJYONzft1+TiUlR0gC4UfyA3CLX99oy1FA/PJYCl 562 KFyNeORqXl0RtzgEcbwNDjYbwujHUgdIFvI8f+1c+qvpjwIDAQABoyEwHzAdBgNV 563 HQ4EFgQUKcxEepHj4Yr7+WDTS28DWxXcIvMwDQYJKoZIhvcNAQEFBQADgYEAVYsY 564 /ZghXf3TfAR6eW6MmQpzPR0oBO9JHjf4Wic87WkxCFPNW/pSIMO67ZoIOjU4b0Is 565 VOmcyPSHP8q0a0DS4f3rt9wF6VypcxLtaqkFD4lMRaoYNPvSwTSEBJj5yioPYsl7 566 OV5UgywTR5QueYK7YFyY+7gwUksTwtka6IIBlTk= 567 -----END CERTIFICATE----- 569 Then if the signer signs the alert with the above private key and the 570 token "foobar", he will create the following ESCAPE message: 572 Content-Type: multipart/signed; 573 protocol="application/pkcs7-signature"; 574 micalg="sha1"; 575 boundary="----C16CFF6F1CB606631B8BBD4B5B43051F" 577 ------C16CFF6F1CB606631B8BBD4B5B43051F 578 Alert-Token: asdfasdfasdf 579 Content-Type: application/cap+xml 581 582 583 43b080713727 584 hsas@dhs.gov 585 2003-04-02T14:39:01-05:00 586 Actual 587 Alert 588 Public 589 590 Security 591 Homeland Security Advisory System Update 592 Immediate 593 Severe 594 Likely 595 U.S. Government, 596 Department of Homeland Security 597 Homeland Security Sets Code ORANGE 598 The Department of Homeland Security has 599 elevated the Homeland Security Advisory System threat level 600 to ORANGE / High in response to intelligence which may 601 indicate a heightened threat of terrorism. 602 A High Condition is declared when there is a 603 high risk of terrorist attacks. In addition to the 604 Protective Measures taken in the previous Threat Conditions, 605 Federal departments and agencies should consider agency- 606 specific Protective Measures in accordance with their 607 existing plans. 608 http://www.dhs.gov/dhspublic/display?theme=29 609 610 HSAS 611 ORANGE 612 613 614 Image file (GIF) 615 http://www.dhs.gov/dhspublic/getAdvisoryImage 616 617 618 U.S. nationwide and interests worldwide 619 620 621 623 ------C16CFF6F1CB606631B8BBD4B5B43051F 624 Content-Type: application/pkcs7-signature; name="smime.p7s" 625 Content-Transfer-Encoding: base64 626 Content-Disposition: attachment; filename="smime.p7s" 628 MIIBxQYJKoZIhvcNAQcCoIIBtjCCAbICAQMxCTAHBgUrDgMCGjALBgkqhkiG9w0B 629 BwExggGTMIIBjwIBA4AUKcxEepHj4Yr7+WDTS28DWxXcIvMwBwYFKw4DAhqggdgw 630 GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDA0 631 MTUzMzM4WjAjBgkqhkiG9w0BCQQxFgQUG0dU/Z+LJg/29/4nvzkou4Bion4weQYJ 632 KoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFl 633 AwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw 634 BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBDIjpmJ2uP 635 nbFJqb35p7dGKdoWyh0Q0LUKr9SxOWkmvK9K6AB/Bodzlo1U5hGVqX10p7HqUWW9 636 SMt3DXB8sxSbEOrD0HUsdsQvmoulfWNAX5ZphS7jvy1LeR9qrYp8zyzUd1bWSOZA 637 kQKwpg6PRyVYArqG8uAD00CW0elL34WKLQ== 639 ------C16CFF6F1CB606631B8BBD4B5B43051F-- 641 If the signer also applies the GZIP encoding and attaches the token, 642 he will create the following ESCAPE message: 644 Content-Type: multipart/signed; 645 protocol="application/pkcs7-signature"; 646 micalg="sha1"; 647 boundary="----C6A0932DF53B0609D38DC49A7E492DB3" 649 ------C6A0932DF53B0609D38DC49A7E492DB3 650 Alert-Token: foobar 651 Content-Type: application/cap+xml 652 Content-Transfer-Encoding: base64 653 Content-Encoding: gzip 655 H4sIADZhik4AA4VUW27bMBD8L5A7LPzVArUpJynSCopSI2keQF+onQMw5NoiQpE 656 CSdnx7bukJFtBi/ZL4nBn9sktrl5qDVt0XlkDlzCZz7IJoBFWKrOJwOPqdvpxcl 657 XCyZuCa3QBiGF8vGqdyS33yueG1+jzIHKs0W2Ivs8Fb/L5bD6JRCiURBPUWqErz 658 8+eso/Zxfzs4vSiYKMLgGTq0Ug6VZ77z7Lys43dFqwHjyahPM2ys2l2Ps1OV/Pz 659 /OxTns2n2Yc8y5J16Pz6wEPry4UILdd00R17mdpvVvsGy0VMq2DDsSMKS78/2ye 660 tBPHSqacps7bJCKAQPODGun25RNE6FfYFO0AAHYHMcBsjurc1am4kDMawkFvlyR 661 aWex+whsdGErtgnf1IoO2qWj7UNUqVbAZoZOWJF3UpGvrBWIgeGBkJSpYrQ+BX9 662 Yw6RnxAXmnFin+nxpaPs+UM7ixJmZriet9Z3GDDXYgA2DX8kdvQs6TQa1bIpVYG 663 /1KJJQYP11Yi/Pi1+H73pWAH454s0QunmkCDWq4q/J9/qLjvmKhxSxWTEIj1/x6 664 EyiEPQCTUiR9sHxMwuFebCpQBh76xxmO8pMqh1ip2A2FXKVFBzfedb2WkigMBHC 665 okbkCTAkkuKOyAzlmnfD0r2DjBPmdlfHCt6KBF5/3akmZEQHmQKDR3JLmr0MQEH 666 UaYd/wq2pP689hVAB4CF89+Bg8GuOzFKJFYn8T76WxA8rpF+Ibct5QtBP5MHlRy 667 Ao3DrbKth1WXySEm3w/HLVLruab4hiZRUFR1HqukSM5XttUSBFFoBbjuYj9NZN+ 668 goJUg/hoHRcCFsE7yVG4VqhiRcn2vXyjBuLkaarKnor6q4DDbO3wqqxCanLHdbj 669 frtwyjb5MePJPKk8D+ipRrvDz9VLBI6dmUEc10iOsoAQRtuW4xTfr9crEs2PH82 670 qQchrs79YJspHh8gJSsbZ0YSQzIDQ0KbQIqGayVRnh793D7rmCvro9CaXuof+e7 671 wTA8g6Qbt4s6hHeM5BgdDR3vzmNHEU3u08owPJZ9R/1NvY/vhKRoEnbWaRnxgh0 672 YI23Wi8dly4ZtS2hc0+XJm9+QWcJ8tAYAAA== 674 ------C6A0932DF53B0609D38DC49A7E492DB3 675 Content-Type: application/pkcs7-signature; name="smime.p7s" 676 Content-Transfer-Encoding: base64 677 Content-Disposition: attachment; filename="smime.p7s" 679 MIIBxQYJKoZIhvcNAQcCoIIBtjCCAbICAQMxCTAHBgUrDgMCGjALBgkqhkiG9w0B 680 BwExggGTMIIBjwIBA4AUKcxEepHj4Yr7+WDTS28DWxXcIvMwBwYFKw4DAhqggdgw 681 GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDA0 682 MDEyODIyWjAjBgkqhkiG9w0BCQQxFgQUh4vjrIyFiLJE0T6IK4OksdV+zBAweQYJ 683 KoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFl 684 AwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw 685 BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB4SiBnr3vC 686 T//nsi1NuSsb5/uSfBvJjtlTyr1SuqLaanqbeSoASflaqu6N/07LZpQI4m1PRq8V 687 Qa/4HO0IDLAuYlwdXUoHQWcqePla6WHTp4U6s358JFkr2bg47nZ6Sgr41MMdC+9P 688 OYWrmvTPTQOX/vbSUFAApJg4QP3O6PKunA== 690 ------C6A0932DF53B0609D38DC49A7E492DB3-- 692 6. IANA Considerations 694 This document requires no action by IANA. 696 7. Security Considerations 698 This document defines a secure alert format that allows alert 699 originators to apply S/MIME digital signatures to a CAP alerts 700 [RFC5751], and to enclose an additional rough authenticator based on 701 a one-time password scheme [RFC2289]. The security considerations 702 discussed in the specifications for those security mechanisms apply 703 here as well. 705 This document does not address the question of which signers or alert 706 tokens should be accepted as authorized alert originators. There is 707 a need for some out of band process for provisioning public keys and 708 alert token hashes to potential alert recipients. Obviously, if that 709 process can be exploited to cause alert recipients to trust an 710 unauthorized public key, then affected recipients will be at risk of 711 accepting inappropriate alerts under that public key (assuming the 712 attacker can deliver the alert to the recipient). The risk is lower 713 with regard to alert token hashes, because they are only used as a 714 rough check to avoid signature verification on obviously bogus 715 alerts. If an attacker can cause only unauthorized alert hashes to 716 be provisioned as trusted, and not unauthorized public keys, then he 717 will only be able to waste resources on recipient devices by forcing 718 them to verify bogus signatures. 720 Finally, a note on the choice of security technology. The CAP 721 specification does provide for alert signing, using XML-DSig. In 722 this document, we use S/MIME as a simpler mechanism for signing. 723 Because S/MIME signs over a serialization of an XML document rather 724 than the logical structure of the document, it does not require XML 725 canonicalization (as XML-DSig does). Using S/MIME also means that 726 ESCAPE can accommodate alerts that are not encoded in XML, such as 727 DER-encoded CAP alerts, both because the signature computation is 728 agnostic to the format of the signed content and because MIME 729 provides content type indication. 731 8. Acknowledgements 733 [TODO] 735 9. References 736 9.1. Normative References 738 [CAP] Botterell, A. and E. Jones, "Common Alerting Protocol 739 v1.1", October 2005. 741 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 742 Mail: Part I: Message Encryption and Authentication 743 Procedures", RFC 1421, February 1993. 745 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 746 Randers-Pehrson, "GZIP file format specification version 747 4.3", RFC 1952, May 1996. 749 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 750 Extensions (MIME) Part One: Format of Internet Message 751 Bodies", RFC 2045, November 1996. 753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 754 Requirement Levels", BCP 14, RFC 2119, March 1997. 756 [RFC2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One- 757 Time Password System", RFC 2289, February 1998. 759 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 760 Algorithms", RFC 3370, August 2002. 762 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 763 Description Protocol", RFC 4566, July 2006. 765 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 766 Encodings", RFC 4648, October 2006. 768 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 769 Specifications: ABNF", STD 68, RFC 5234, January 2008. 771 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 772 Housley, R., and W. Polk, "Internet X.509 Public Key 773 Infrastructure Certificate and Certificate Revocation List 774 (CRL) Profile", RFC 5280, May 2008. 776 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 777 RFC 5652, September 2009. 779 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 780 Mail Extensions (S/MIME) Version 3.2 Message 781 Specification", RFC 5751, January 2010. 783 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 784 Message Syntax", RFC 5754, January 2010. 786 9.2. Informative References 788 [I-D.ietf-atoca-requirements] 789 Schulzrinne, H., Norreys, S., Rosen, B., and H. 790 Tschofenig, "Requirements, Terminology and Framework for 791 Exigent Communications", draft-ietf-atoca-requirements-03 792 (work in progress), March 2012. 794 Authors' Addresses 796 Richard Barnes 797 BBN Technologies 798 9861 Broken Land Parkway 799 Columbia, MD 21046 800 US 802 Phone: +1 410 290 6169 804 Andrew Chi 805 BBN Technologies 806 10 Moulton St 807 Cambridge, MA 02138 808 US 810 Phone: +1 617 873 2574