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