ATOCA R. Barnes Internet-Draft BBN Technologies Intended status: Informational October 6, 2011 Expires: April 8, 2012 Encoding of Secure Common Alert Protocol Entities (ESCAPE) draft-barnes-atoca-escape-00.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 April 8, 2012. Copyright Notice Copyright (c) 2011 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 Expires April 8, 2012 [Page 1] Internet-Draft ESCAPE October 2011 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 . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. new section . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Basic MIME encoding . . . . . . . . . . . . . . . . . . . 4 3.2. Alert Tokens . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. S/MIME Encapsulation . . . . . . . . . . . . . . . . . . . 5 3.4. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Alert Originator (Signer) . . . . . . . . . . . . . . . . 6 4.2. Alert Relay (Re-signer) . . . . . . . . . . . . . . . . . 7 4.3. Alert Recipient (Verifier) . . . . . . . . . . . . . . . . 8 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Barnes Expires April 8, 2012 [Page 2] Internet-Draft ESCAPE October 2011 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. 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 control. While it is still important for the "staging" or "distribution" step be secure, the alerting system would be more robust if security were provided end-to-end, from the original authority to the end recipient. 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. The ESCAPE format defines only a mechanism for signing alerts. It does not define how an alert recipient discovers public keys for entities that it should trust to originate alerts, such as local network operators or local alert authorities. This document assumes that cryptographic parameters such as public keys and "alert tokens" have been provisioned through some other mechanism, e.g., [ATOCA-DOC- TBD]. 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 Expires April 8, 2012 [Page 3] Internet-Draft ESCAPE October 2011 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. new section 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 Expires April 8, 2012 [Page 4] Internet-Draft ESCAPE October 2011 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 a list of valid tokens (or an algorithm for checkign the validity of a token), 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 for the field is as follows, where "base64" is as defined in RFC 4566 [RFC4566][RFC2234]. (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. 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 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 rather than by subject name, in order to allow for both certified and uncertified public keys [RFC5652]. 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. Barnes Expires April 8, 2012 [Page 5] Internet-Draft ESCAPE October 2011 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. 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 ID o gzip flag o List of tokens (possibly empty) Processing steps: 1. Encode the CAP document as a MIME entity. Barnes Expires April 8, 2012 [Page 6] Internet-Draft ESCAPE October 2011 A. Add a "Content-Type" header field with value "application/ common-application-protocol+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 "Access-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. 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. Barnes Expires April 8, 2012 [Page 7] Internet-Draft ESCAPE October 2011 Output: ESCAPE message 4.3. Alert Recipient (Verifier) Inputs: o ESCAPE object o Set of trusted public keys (possibly empty) o Set of valid tokens (possibly empty) Processing steps: 1. 2. Extract the CAP MIME entity and the CMS SignedData object from the ESCAPE message. 3. Check that the MIME headers for the CAP MIME entity have the correct values. * Content-Type must be "application/ common-alerting-protocol+xml" * Content-Encoding must be "gzip" or absent * 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. 4. Extract the CAP entity body. If the Content-Encoding is "gzip", then base64-decode and un-gzip the CAP entity body. 5. If the set of valid tokens is non-empty, then verify that at least one of the Alert-Token values in the CAP MIME entity is contained within the set of valid tokens. If no Alert-Token value is valid, then return FALSE. 6. 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. 7. Return TRUE. Barnes Expires April 8, 2012 [Page 8] Internet-Draft ESCAPE October 2011 Output: Verification status 5. Examples Consider the following CAP message: 43b080713727 hsas@dhs.gov 2003-04-02T14:39:01-05:00 Actual Alert Public Security Homeland Security Advisory System Update Immediate Severe Likely U.S. Government, Department of Homeland Security Homeland Security Sets Code ORANGE 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. 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. http://www.dhs.gov/dhspublic/display?theme=29 HSAS ORANGE Image file (GIF) http://www.dhs.gov/dhspublic/getAdvisoryImage U.S. nationwide and interests worldwide Barnes Expires April 8, 2012 [Page 9] Internet-Draft ESCAPE October 2011 Suppose an alert signer has the following RSA key pair, encoded as a PEM-encoded private key and self-signed certificate [RFC1421]: -----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 Barnes Expires April 8, 2012 [Page 10] Internet-Draft ESCAPE October 2011 43b080713727 hsas@dhs.gov 2003-04-02T14:39:01-05:00 Actual Alert Public Security Homeland Security Advisory System Update Immediate Severe Likely U.S. Government, Department of Homeland Security Homeland Security Sets Code ORANGE 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. 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. http://www.dhs.gov/dhspublic/display?theme=29 HSAS ORANGE Image file (GIF) http://www.dhs.gov/dhspublic/getAdvisoryImage U.S. nationwide and interests worldwide ------C16CFF6F1CB606631B8BBD4B5B43051F Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIBxQYJKoZIhvcNAQcCoIIBtjCCAbICAQMxCTAHBgUrDgMCGjALBgkqhkiG9w0B Barnes Expires April 8, 2012 [Page 11] Internet-Draft ESCAPE October 2011 BwExggGTMIIBjwIBA4AUKcxEepHj4Yr7+WDTS28DWxXcIvMwBwYFKw4DAhqggdgw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDA0 MTUzMzM4WjAjBgkqhkiG9w0BCQQxFgQUG0dU/Z+LJg/29/4nvzkou4Bion4weQYJ 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 Expires April 8, 2012 [Page 12] Internet-Draft ESCAPE October 2011 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 Expires April 8, 2012 [Page 13] Internet-Draft ESCAPE October 2011 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. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 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. Barnes Expires April 8, 2012 [Page 14] Internet-Draft ESCAPE October 2011 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [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-01 (work in progress), January 2011. Author's Address Richard Barnes BBN Technologies 9861 Broken Land Parkway Columbia, MD 21046 US Phone: +1 410 290 6169 Barnes Expires April 8, 2012 [Page 15]