Encoding of Secure Common Alert Protocol Entities (ESCAPE)
draft-barnes-atoca-escape-01

ATOCA                                                          R. Barnes
Internet-Draft                                                    A. Chi
Intended status: Informational                          BBN Technologies
Expires: March 15, 2013                               September 11, 2012

       Encoding of Secure Common Alert Protocol Entities (ESCAPE)
                    draft-barnes-atoca-escape-01.txt

Abstract

   Recipients of emergency alerts need to be able to verify that an
   alert they receive was issued by an authorized source.  The Common
   Alerting Protocol (CAP) provides a standard way of encoding alert
   information, but does not provide any security features that would
   support authentication of alert originators.  This document describes
   a security wrapper for Common Alerting Protocol objects to allow
   alerts to be signed by alert originators.

   Please send feedback to the atoca@ietf.org mailing list.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 15, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Barnes & Chi             Expires March 15, 2013                 [Page 1]
Internet-Draft                   ESCAPE                   September 2012

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Open Questions . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  ESCAPE Encoding  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Basic MIME encoding  . . . . . . . . . . . . . . . . . . .  5
     3.2.  Alert Tokens . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  S/MIME Encapsulation . . . . . . . . . . . . . . . . . . .  6
     3.4.  Validity . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Processing Rules . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Alert Originator (Signer)  . . . . . . . . . . . . . . . .  8
     4.2.  Alert Relay (Re-signer)  . . . . . . . . . . . . . . . . .  9
     4.3.  Alert Recipient (Verifier) . . . . . . . . . . . . . . . .  9
   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17

Barnes & Chi             Expires March 15, 2013                 [Page 2]
Internet-Draft                   ESCAPE                   September 2012

1.  Introduction

   Emergency alerting is an increasingly important function of
   telecommunications networks, allowing authorities to distribute
   warnings of impending danger to large numbers of end users in a short
   period of time.  However, because emergency alerts are such important
   messages to users, there is much more potential for abuse of alerting
   than other messaging systems.  If an attacker can introduce a false
   emergency alert, he may be able to cause mass action, such as the
   evacuation of a building or city.

   Traditionally, the security of alerting systems has been based mainly
   on the security of the system by which authorities provide alerts to
   broadcast points, and on the link-layer security of broadcast media
   that deliver alerts to end users.  For example, alerting systems for
   cellular networks typically rely on sending alerts over the cellular
   control plane, so that only the local carrier can deliver alerts to
   an end device.  Alerting via broadcast media such as television or
   radio is protected by legal limitations on the ability to transmit
   above certain power thresholds in portions of spectrum used for
   broadcast media (e.g., television stations).

   In the context of the Internet, it is impossible to rely on link-
   layer security because IP runs over many types of link that have no
   analogous access controls.  Indeed, alerts may transit multiple
   different types of network en route to end devices.  For example, if
   an alert is delivered to a device that routes between cellular,
   Ethernet, and 802.11 interfaces, the router may need to translate an
   alert delivered by the cellular control plane into an IP datagram
   that can be delivered over Ethernet or 802.11.  There is thus a need
   for an end-to-end security mechanism for alerts, so that an endpoint
   can verify that an alert is authentic even if the alert arrives over
   an untrusted interface.

   This document describes ESCAPE, a secure container format for the
   Common Alerting Protocol (CAP) [CAP].  CAP documents provide
   information about an emergency alert; ESCAPE-wrapped CAP documents
   also provide security information that can authenticate the
   originator of the alert.  Using this additional information, end
   alert recipients can verify that ESCAPE-wrapped alerts were
   originated by entities they trust, and reject false alerts from
   untrusted entities.

   Note that ESCAPE validation is not a complete security solution for
   alerting.  ESCAPE validation will authenticate the originator of an
   alert; it is up to the device to determine whether the originator is
   trusted.  In general, this will require that devices be provisioned
   with credentials for trusted entities, either via manual provisioning

Barnes & Chi             Expires March 15, 2013                 [Page 3]
Internet-Draft                   ESCAPE                   September 2012

   (e.g., static keys in device firmware) or by some dynamic
   provisioning protocol.

   For purposes of this document, we assume that endpoints can be
   provisioned with two types of credentials: public keys and "alert
   token hashes".  A public key for an authority is used to validate
   digital signatures by that authority.  An alert token is a random
   nonce that is used as a fast authentication check.  Clients are
   provisioned with hashed versions of a collection of tokens (such that
   the tokens themselves are known only to an authorized server).  On
   receiving an alert token, a client computes a hash of the token and
   compares it to the list of pre-computed hash values with which it is
   provisioned.  (Thus, alongside alert tokens, the provisioning system
   must specify the hash function used to verify the alert token.)  The
   detailed steps for verifying an ESCAPE object using a collection of
   provisioned public keys and alert tokens is described in Section 4.3.

   The high-level operation of an ESCAPE-based alerting system can be
   summarized as follows:

   1.  Endpoints are provisioned with public keys and/or alert token
       hashes for authorities.

   2.  When an authority wishes to generate an alert, it includes an
       alert token and signs it using its private key (Section 4.1)

   3.  The alert is distributed to one or more endpoints.

   4.  Along the way, an intermediary may add a signature to the object
       (Section 4.2).

   5.  When the alert arrives at an endpoint, the endpoint validates the
       signature and alert token (Section 4.3).  If both are valid, it
       renders the alert to the user.

   This document defines procedures for generating, re-signing, and
   verifying alerts (steps 2, 4, and 5 above).  The mechanisms used for
   provisioning trusted credentials (step 1) and for the actual delivery
   of alerts (step 3) are beyond the scope of this document.

1.1.  Open Questions

   Should we always apply GZIP to the entire encoded message?  Pro:
   Slightly smaller message size.  Con: Will need to require GZIP for
   all messages or add content indication.

   Should we allow DER-encoded CAP as well as XML-encoded CAP?  Pro:
   Smaller message size.  Con: Clients need to support two encodings.

Barnes & Chi             Expires March 15, 2013                 [Page 4]
Internet-Draft                   ESCAPE                   September 2012

   Should we constrain crypto algorithms.  Pro: Marginally simpler
   implementation.  Con: Need to maintain a list of supported
   algorithms.

   Should we require a public-key signature, or allow reliance on token
   checks alone?  Pro: Enables cases with no public-key operations.
   Con: Risk of replay attacks using old tokens.

   Should we move the Alert-Token field from the inner (signed) MIME
   entity to the outer (unsigned) MIME entity?  Pro: Allows relays to
   add tokens.  Con: Allows relays and attackers to remove or change
   tokens.

2.  Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  ESCAPE Encoding

   The ESCAPE format encapsulates a CAP document as an S/MIME object
   [RFC5751].  First, the CAP document is encoded as a MIME entity
   [RFC2045], then the MIME entity is signed using S/MIME.

3.1.  Basic MIME encoding

   CAP XML documents have MIME type "application/cap+xml".  An alert
   originator may choose to apply the gzip compression scheme to the
   alert before sending it.  If the alert is compressed, the originator
   must encode the compressed alert using the base64 encoding scheme
   before transmitting it [RFC1952][RFC4648].  A CAP MIME body thus has
   the following properties:

   o  A "Content-Type" header field MUST be present, with the single
      value "application/cap+xml".

   o  A "Content-Encoding" header field MAY be present.  If present, it
      MUST have the value "gzip", and there MUST be a "Content-Transfer-
      Encoding" header with the value "base64".

   o  The body of the MIME entity MUST be a CAP document, either
      directly, or processed through the gzip and base64 encodings.

Barnes & Chi             Expires March 15, 2013                 [Page 5]
Internet-Draft                   ESCAPE                   September 2012

3.2.  Alert Tokens

   ESCAPE introduces a new MIME header, Alert-Token, which provides a
   rough form of authentication.  If alert recipients are configured
   with an algorithm for checking the validity of a token, along with
   the appropriate authentication material, the recipient of an alert
   message can check the validity of the value in the Alert-Token field
   before performing full S/MIME validation on the ESCAPE object.  The
   Alert-Token field contains a single opaque binary string, encoded in
   base64.  The ABNF syntax ([RFC5234]) for the field is as follows,
   where "base64" is as defined in RFC 4566 [RFC4566].  (Here we also
   follow the usual conventions with regard to whitespace in MIME
   headers.)
   Alert-Token = "Alert-Token" ":" base64

   An ESCAPE MIME entity MAY contain one or more Alert-Token header
   fields.  Any header fields other than "Content-Type", "Content-
   Encoding", "Content-Transfer-Encoding", and "Alert-Token" MAY be
   ignored by alert recipients.

   The Alert-Token authentication system implements a hash-preimage
   scheme.  Such a scheme can provide rough authentication when the
   communication channel is adequately integrity-protected (e.g., by the
   signature on the ESCAPE object).  The Alert Originator, such as a
   government authority, first generates a list of one-time-use alert
   tokens, which are initially kept secret, known only to the Alert
   Originator.  The Alert Originator computes cryptographic hashes of
   the alert tokens and publishes the list of hashes (out-of-band) so
   that every Alert Recipient device is provisioned with the known list
   if hashes.

   When sending an emergency alert, the Alert Originator inserts an
   unused alert tokens in an Alert-Token header in the ESCAPE message
   and transmits the alert.  An Alert Recipient device receiving the
   message verifies the Alert-Token by computing the hash value of the
   alert token and searching through its known list of hashes.  If a
   match is found, then the alert token is considered valid.  Otherwise,
   the alert token is considered invalid.  To diminish the chances of
   replay, when the Alert Recipient encounters a valid Alert-Token, it
   MUST remove the corresponding hash from its known list.

3.3.  S/MIME Encapsulation

   After a CAP message has been encoded into a MIME entity, an S/MIME
   signature is applied, following the S/MIME procedures for
   constructing a signed message of type "multipart/signed" (Section 3.4
   of RFC 5751 [RFC5751]).  The following constraints apply to the

Barnes & Chi             Expires March 15, 2013                 [Page 6]
Internet-Draft                   ESCAPE                   September 2012

   S/MIME encoding used in ESCAPE messages.

   o  The ESCAPE message MUST have type "multipart/signed".

   o  If the ESCAPE message contains header fields other than "Content-
      Type", then they MAY be ignored.

   o  The S/MIME body part SHOULD NOT include certificates for signers,
      in order to minimize message size.

   o  The S/MIME body part SHOULD identify signers by subject key
      identifier (SKI) rather than by subject name, in order to allow
      for both certified and uncertified public keys [RFC5652].  If the
      SKI is used to identify signers, then it MUST be equal to the 160-
      bit SHA-1 hash of the value of the BIT STRING subjectPublicKey as
      specified in Section 4.2.1.2 of [RFC5280].

   Except the constraints above, software to verify ESCAPE alerts MUST
   include full S/MIME support, including all defined cryptographic
   algorithms [RFC3370][RFC5754].  Implementations MAY include
   additional algorithms, but alert signers SHOULD NOT sign alerts with
   non-standard algorithms, since some recipients may not be able to
   process them.

3.4.  Validity

   An ESCAPE object is valid if and only if all of the following
   conditions are true:

   o  If the verifying entity is configured with valid tokens, then
      there must be at least one Alert-Token header field containing a
      valid token.

   o  If the verifying entity is configured with trusted public keys,
      then the S/MIME signature on the object must be valid, and must be
      verified using a trusted public key.

   An entity verifying an ESCAPE object MUST verify both of these
   criteria, but MAY check them in either order and omit further checks
   after the object fails one check.  In particular, performing the
   token check before decoding and verifying the CMS signature may avoid
   the work of signature verification.  A verifying entity SHOULD NOT
   accept ESCAPE objects if it is configured with neither trusted public
   keys nor valid tokens.

Barnes & Chi             Expires March 15, 2013                 [Page 7]
Internet-Draft                   ESCAPE                   September 2012

4.  Processing Rules

   There are three main phases in the life-cycle of an ESCAPE object.
   First, it is created and signed by an alert originator.  Second, it
   may pass through an alert relay that adds a signature under its key.
   Finally, it is received and verified by an end recipient.  This
   section describes the steps that each type of entity follows to sign,
   re-sign or verify an ESCAPE object.

4.1.  Alert Originator (Signer)

   Inputs:

   o  CAP document

   o  Private key for signing, and corresponding subject key identifier

   o  gzip flag

   o  List of tokens (possibly empty)

   Processing steps:

   1.  Encode the CAP document as a MIME entity.

       A.  Add a "Content-Type" header field with value "application/
           cap+xml".

       B.  If the gzip flag is set, add a "Content-Encoding" header
           field with value "gzip" and a "Content-Transfer-Encoding"
           header field with value "base64".

       C.  Add an "Alert-Token" header field for each token in the list.

       D.  If the gzip flag is set, gzip the CAP document, then gzip and
           base64-encode the CAP document and set it as the message
           body.

       E.  If the gzip flag is not set, set the CAP document as the
           message body.

   2.  Compute the signature over the MIME entity using the signing key
       and create a CMS SignedData structure that identifies the signer
       using the corresponding subject key ID.

   3.  Combine the CAP MIME entity and the computed CMS SignedData
       structure into a "multipart/signed" S/MIME object.

Barnes & Chi             Expires March 15, 2013                 [Page 8]
Internet-Draft                   ESCAPE                   September 2012

   Output: ESCAPE message

4.2.  Alert Relay (Re-signer)

   Inputs:

   o  ESCAPE object

   o  Private key for signing and corresponding subject key ID

   Processing steps:

   1.  Extract the CAP MIME entity and CMS SignedData object from the
       ESCAPE message.

   2.  Compute the signature over the CAP MIME entity using the signing
       key.

   3.  Append the signature value and subject key ID to the CMS
       SignedData object as a new SignerInfo.

   4.  Combine the CAP MIME entity and the computed CMS SignedData
       structure into a "multipart/signed" S/MIME object.

   Output: ESCAPE message

4.3.  Alert Recipient (Verifier)

   Inputs:

   o  ESCAPE object

   o  Set of trusted public keys (possibly empty)

   o  Set of trusted alert tokens hashes (possibly empty)

   Processing steps:

   1.  Extract the CAP MIME entity and the CMS SignedData object from
       the ESCAPE message.

   2.  Check that the MIME headers for the CAP MIME entity have the
       correct values.

       *  Content-Type must be "application/cap+xml"

       *  Content-Encoding must be "gzip" or absent

Barnes & Chi             Expires March 15, 2013                 [Page 9]
Internet-Draft                   ESCAPE                   September 2012

       *  Content-Transfer-Encoding must be present and equal to
          "base64" if Content-Encoding is present, otherwise absent.

       If any of these headers are invalid, then return the CAP message
       is malformed.  Return FALSE.

   3.  Extract the CAP entity body.  If the Content-Encoding is "gzip",
       then base64-decode and un-gzip the CAP entity body.

   4.  If the set of trusted alert token hashes is non-empty, then
       verify that at least one of the Alert-Token values in the CAP
       MIME entity is a valid token, using the algorithm described in
       Section 3.2, If no valid alert token is provided, then return
       FALSE.

   5.  If the set of trusted public keys is non-empty, then verify that
       at least one of the SignerInfos within the CMS SignedData object
       contains a valid signature under a trusted key.  If no valid,
       trusted signature is found, then return FALSE.

   6.  Return TRUE.

   Output: Verification status

5.  Examples

   Consider the following CAP message:

Barnes & Chi             Expires March 15, 2013                [Page 10]
Internet-Draft                   ESCAPE                   September 2012

   <?xml version = "1.0" encoding = "UTF-8"?>
   <alert xmlns = "urn:oasis:names:tc:emergency:cap:1.1">
    <identifier>43b080713727</identifier>
    <sender>hsas@dhs.gov</sender>
    <sent>2003-04-02T14:39:01-05:00</sent>
    <status>Actual</status>
    <msgType>Alert</msgType>
    <scope>Public</scope>
    <info>
      <category>Security</category>
      <event>Homeland Security Advisory System Update</event>
      <urgency>Immediate</urgency>
      <severity>Severe</severity>
      <certainty>Likely</certainty>
      <senderName>U.S. Government,
      Department of Homeland Security</senderName>
      <headline>Homeland Security Sets Code ORANGE</headline>
      <description>The Department of Homeland Security has
      elevated the Homeland Security Advisory System threat level
      to ORANGE / High in response to intelligence which may
      indicate a heightened threat of terrorism.</description>
      <instruction> A High Condition is declared when there is a
      high risk of terrorist attacks. In addition to the
      Protective Measures taken in the previous Threat Conditions,
      Federal departments and agencies should consider agency-
      specific Protective Measures in accordance with their
      existing plans.</instruction>
      <web>http://www.dhs.gov/dhspublic/display?theme=29</web>
      <parameter>
        <valueName>HSAS</valueName>
        <value>ORANGE</value>
      </parameter>
      <resource>
        <resourceDesc>Image file (GIF)</resourceDesc>
        <uri>http://www.dhs.gov/dhspublic/getAdvisoryImage</uri>
      </resource>
      <area>
        <areaDesc>U.S. nationwide and interests worldwide</areaDesc>
      </area>
    </info>
   </alert>

   Suppose an alert signer has the following RSA key pair, encoded as a
   PEM-encoded private key and self-signed certificate [RFC1421]:

Barnes & Chi             Expires March 15, 2013                [Page 11]
Internet-Draft                   ESCAPE                   September 2012

   -----BEGIN PRIVATE KEY-----
   MIICeAIBADANBgkqhkiG9w0BAQEFAASCAmIwggJeAgEAAoGBAMqjkUYoHtH+uLPo
   w3FNAlpHyT5BG0KWjN6hG7LUgh2GP+c2wmyavn9+ShwEe1CG9qgwa1apqNl/7BTY
   UoRTCsSMlg43N+3X5OJSVHSALhR/IDcItf32jLUUD88lgKUoXI145GpeXRG3OARx
   vA0ONhvC6MdSB0gW8jx/7Vz6q+mPAgMBAAECgYB2sqtlMhkjnxaoY/8f/iETqxsp
   uU9ziOaJfkvQTATPsJT8JiprHZXa7qoQkVt+hyAy0vH9OLJsfS9X4oMrec1C22Jm
   1EUqOqg+CXLye0OPSYckZukEPAt3EyQNBg4BIZFWC4ouKVcy0UECuL5X6oZ5Z5us
   nMJ0wHI8n6ghiY620QJBAPFm6sNOOZqs0jFutbHWm5eQ7vbNynGYcm4S2v7Esnyn
   GKy2iMf8MMiJjqmJiYQ47wn/Rm5rljNu/eTPNopcKhkCQQDW5JGsV6piWLN4fvg9
   tpv0OG/mqJUBwjEejGg0LzupQiHociEg+cm+IPP61NX/MXoQXQIoFKcc6nXXq4rt
   +PXnAkEAiurg2nefqqUdaJj/MlH/w98BxUFz6J8D6tgq8kWbOSSnjGyWlg9Iu359
   fI7Ldi2VUbl3fH+pNfv/W7bq+gBDsQJBAMKNsa18uQ/NCr9/BLSqzUswhW8pFa6/
   58SmjfkhAjzdWOGf4op+W749C2b+prgiTUbfTgKHoDy3sPUPo/qLueUCQQCdIdRB
   3SrfM1gedy2h20RiFu6Ew1GCFSK2DUv60BcZJmbazVCNFQq8wBtHuqHew/7hxmtA
   DtxHTLote/VHyOj7
   -----END PRIVATE KEY-----

   -----BEGIN CERTIFICATE-----
   MIICKTCCAZKgAwIBAgIJAIGuauj9u0i0MA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV
   BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
   aWRnaXRzIFB0eSBMdGQwHhcNMTExMDAzMjEzNDIzWhcNMTIxMDAyMjEzNDIzWjBF
   MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
   ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
   gQDKo5FGKB7R/riz6MNxTQJaR8k+QRtClozeoRuy1IIdhj/nNsJsmr5/fkocBHtQ
   hvaoMGtWqajZf+wU2FKEUwrEjJYONzft1+TiUlR0gC4UfyA3CLX99oy1FA/PJYCl
   KFyNeORqXl0RtzgEcbwNDjYbwujHUgdIFvI8f+1c+qvpjwIDAQABoyEwHzAdBgNV
   HQ4EFgQUKcxEepHj4Yr7+WDTS28DWxXcIvMwDQYJKoZIhvcNAQEFBQADgYEAVYsY
   /ZghXf3TfAR6eW6MmQpzPR0oBO9JHjf4Wic87WkxCFPNW/pSIMO67ZoIOjU4b0Is
   VOmcyPSHP8q0a0DS4f3rt9wF6VypcxLtaqkFD4lMRaoYNPvSwTSEBJj5yioPYsl7
   OV5UgywTR5QueYK7YFyY+7gwUksTwtka6IIBlTk=
   -----END CERTIFICATE-----

   Then if the signer signs the alert with the above private key and the
   token "foobar", he will create the following ESCAPE message:

   Content-Type: multipart/signed;
      protocol="application/pkcs7-signature";
      micalg="sha1";
      boundary="----C16CFF6F1CB606631B8BBD4B5B43051F"

   ------C16CFF6F1CB606631B8BBD4B5B43051F
   Alert-Token: asdfasdfasdf
   Content-Type: application/cap+xml

   <?xml version = "1.0" encoding = "UTF-8"?>
   <alert xmlns = "urn:oasis:names:tc:emergency:cap:1.1">
    <identifier>43b080713727</identifier>

Barnes & Chi             Expires March 15, 2013                [Page 12]
Internet-Draft                   ESCAPE                   September 2012

    <sender>hsas@dhs.gov</sender>
    <sent>2003-04-02T14:39:01-05:00</sent>
    <status>Actual</status>
    <msgType>Alert</msgType>
    <scope>Public</scope>
    <info>
      <category>Security</category>
      <event>Homeland Security Advisory System Update</event>
      <urgency>Immediate</urgency>
      <severity>Severe</severity>
      <certainty>Likely</certainty>
      <senderName>U.S. Government,
      Department of Homeland Security</senderName>
      <headline>Homeland Security Sets Code ORANGE</headline>
      <description>The Department of Homeland Security has
      elevated the Homeland Security Advisory System threat level
      to ORANGE / High in response to intelligence which may
      indicate a heightened threat of terrorism.</description>
      <instruction> A High Condition is declared when there is a
      high risk of terrorist attacks. In addition to the
      Protective Measures taken in the previous Threat Conditions,
      Federal departments and agencies should consider agency-
      specific Protective Measures in accordance with their
      existing plans.</instruction>
      <web>http://www.dhs.gov/dhspublic/display?theme=29</web>
      <parameter>
        <valueName>HSAS</valueName>
        <value>ORANGE</value>
      </parameter>
      <resource>
        <resourceDesc>Image file (GIF)</resourceDesc>
        <uri>http://www.dhs.gov/dhspublic/getAdvisoryImage</uri>
      </resource>
      <area>
        <areaDesc>U.S. nationwide and interests worldwide</areaDesc>
      </area>
    </info>
   </alert>

   ------C16CFF6F1CB606631B8BBD4B5B43051F
   Content-Type: application/pkcs7-signature; name="smime.p7s"
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename="smime.p7s"

   MIIBxQYJKoZIhvcNAQcCoIIBtjCCAbICAQMxCTAHBgUrDgMCGjALBgkqhkiG9w0B
   BwExggGTMIIBjwIBA4AUKcxEepHj4Yr7+WDTS28DWxXcIvMwBwYFKw4DAhqggdgw
   GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDA0
   MTUzMzM4WjAjBgkqhkiG9w0BCQQxFgQUG0dU/Z+LJg/29/4nvzkou4Bion4weQYJ

Barnes & Chi             Expires March 15, 2013                [Page 13]
Internet-Draft                   ESCAPE                   September 2012

   KoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFl
   AwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw
   BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBDIjpmJ2uP
   nbFJqb35p7dGKdoWyh0Q0LUKr9SxOWkmvK9K6AB/Bodzlo1U5hGVqX10p7HqUWW9
   SMt3DXB8sxSbEOrD0HUsdsQvmoulfWNAX5ZphS7jvy1LeR9qrYp8zyzUd1bWSOZA
   kQKwpg6PRyVYArqG8uAD00CW0elL34WKLQ==

   ------C16CFF6F1CB606631B8BBD4B5B43051F--

   If the signer also applies the GZIP encoding and attaches the token,
   he will create the following ESCAPE message:

Barnes & Chi             Expires March 15, 2013                [Page 14]
Internet-Draft                   ESCAPE                   September 2012

   Content-Type: multipart/signed;
      protocol="application/pkcs7-signature";
      micalg="sha1";
      boundary="----C6A0932DF53B0609D38DC49A7E492DB3"

   ------C6A0932DF53B0609D38DC49A7E492DB3
   Alert-Token: foobar
   Content-Type: application/cap+xml
   Content-Transfer-Encoding: base64
   Content-Encoding: gzip

   H4sIADZhik4AA4VUW27bMBD8L5A7LPzVArUpJynSCopSI2keQF+onQMw5NoiQpE
   CSdnx7bukJFtBi/ZL4nBn9sktrl5qDVt0XlkDlzCZz7IJoBFWKrOJwOPqdvpxcl
   XCyZuCa3QBiGF8vGqdyS33yueG1+jzIHKs0W2Ivs8Fb/L5bD6JRCiURBPUWqErz
   8+eso/Zxfzs4vSiYKMLgGTq0Ug6VZ77z7Lys43dFqwHjyahPM2ys2l2Ps1OV/Pz
   /OxTns2n2Yc8y5J16Pz6wEPry4UILdd00R17mdpvVvsGy0VMq2DDsSMKS78/2ye
   tBPHSqacps7bJCKAQPODGun25RNE6FfYFO0AAHYHMcBsjurc1am4kDMawkFvlyR
   aWex+whsdGErtgnf1IoO2qWj7UNUqVbAZoZOWJF3UpGvrBWIgeGBkJSpYrQ+BX9
   Yw6RnxAXmnFin+nxpaPs+UM7ixJmZriet9Z3GDDXYgA2DX8kdvQs6TQa1bIpVYG
   /1KJJQYP11Yi/Pi1+H73pWAH454s0QunmkCDWq4q/J9/qLjvmKhxSxWTEIj1/x6
   EyiEPQCTUiR9sHxMwuFebCpQBh76xxmO8pMqh1ip2A2FXKVFBzfedb2WkigMBHC
   okbkCTAkkuKOyAzlmnfD0r2DjBPmdlfHCt6KBF5/3akmZEQHmQKDR3JLmr0MQEH
   UaYd/wq2pP689hVAB4CF89+Bg8GuOzFKJFYn8T76WxA8rpF+Ibct5QtBP5MHlRy
   Ao3DrbKth1WXySEm3w/HLVLruab4hiZRUFR1HqukSM5XttUSBFFoBbjuYj9NZN+
   goJUg/hoHRcCFsE7yVG4VqhiRcn2vXyjBuLkaarKnor6q4DDbO3wqqxCanLHdbj
   frtwyjb5MePJPKk8D+ipRrvDz9VLBI6dmUEc10iOsoAQRtuW4xTfr9crEs2PH82
   qQchrs79YJspHh8gJSsbZ0YSQzIDQ0KbQIqGayVRnh793D7rmCvro9CaXuof+e7
   wTA8g6Qbt4s6hHeM5BgdDR3vzmNHEU3u08owPJZ9R/1NvY/vhKRoEnbWaRnxgh0
   YI23Wi8dly4ZtS2hc0+XJm9+QWcJ8tAYAAA==

   ------C6A0932DF53B0609D38DC49A7E492DB3
   Content-Type: application/pkcs7-signature; name="smime.p7s"
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename="smime.p7s"

   MIIBxQYJKoZIhvcNAQcCoIIBtjCCAbICAQMxCTAHBgUrDgMCGjALBgkqhkiG9w0B
   BwExggGTMIIBjwIBA4AUKcxEepHj4Yr7+WDTS28DWxXcIvMwBwYFKw4DAhqggdgw
   GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDA0
   MDEyODIyWjAjBgkqhkiG9w0BCQQxFgQUh4vjrIyFiLJE0T6IK4OksdV+zBAweQYJ
   KoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFl
   AwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw
   BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB4SiBnr3vC
   T//nsi1NuSsb5/uSfBvJjtlTyr1SuqLaanqbeSoASflaqu6N/07LZpQI4m1PRq8V
   Qa/4HO0IDLAuYlwdXUoHQWcqePla6WHTp4U6s358JFkr2bg47nZ6Sgr41MMdC+9P
   OYWrmvTPTQOX/vbSUFAApJg4QP3O6PKunA==

   ------C6A0932DF53B0609D38DC49A7E492DB3--

Barnes & Chi             Expires March 15, 2013                [Page 15]
Internet-Draft                   ESCAPE                   September 2012

6.  IANA Considerations

   This document requires no action by IANA.

7.  Security Considerations

   [TODO]

   [Dependency on external configuration of keys/TAs and (optionally)
   tokens]

8.  Acknowledgements

   [TODO]

9.  References

9.1.  Normative References

   [CAP]      Botterell, A. and E. Jones, "Common Alerting Protocol
              v1.1", October 2005.

   [RFC1421]  Linn, J., "Privacy Enhancement for Internet Electronic
              Mail: Part I: Message Encryption and Authentication
              Procedures", RFC 1421, February 1993.

   [RFC1952]  Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.
              Randers-Pehrson, "GZIP file format specification version
              4.3", RFC 1952, May 1996.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
              Algorithms", RFC 3370, August 2002.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

Barnes & Chi             Expires March 15, 2013                [Page 16]
Internet-Draft                   ESCAPE                   September 2012

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, September 2009.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

   [RFC5754]  Turner, S., "Using SHA2 Algorithms with Cryptographic
              Message Syntax", RFC 5754, January 2010.

9.2.  Informative References

   [I-D.ietf-atoca-requirements]
              Schulzrinne, H., Norreys, S., Rosen, B., and H.
              Tschofenig, "Requirements, Terminology and Framework for
              Exigent Communications", draft-ietf-atoca-requirements-03
              (work in progress), March 2012.

Authors' Addresses

   Richard Barnes
   BBN Technologies
   9861 Broken Land Parkway
   Columbia, MD  21046
   US

   Phone: +1 410 290 6169

   Andrew Chi
   BBN Technologies
   10 Moulton St
   Cambridge, MA  02138
   US

   Phone: +1 617 873 2574

Barnes & Chi             Expires March 15, 2013                [Page 17]