ATOCA R.L. Barnes
Internet-Draft BBN Technologies
Intended status: Informational October 25, 2011
Expires: April 27, 2012

Alert Metadata Protocol (AMP)
draft-barnes-atoca-meta-00.txt

Abstract

Recipients of emergency alerts need to discover information about local alerting resources, and to register contact points where they can receive alerts. This document defines a mechanism for IP networks to advertise a local alert information resource, and a protocol that end hosts can use to retrieve local information and register information about themselves.

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 27, 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 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

[TODO]

1.1. Open Questions

Allow use of JOSE to protect messages on a per-message basis?

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. Server Discovery

[DHCP option, NAPTR tag]

[Client process: Look for DHCP, then try reverse]

3.1. DHCP Option Format

[TODO]

3.2. DNS NAPTR Record Format

[TODO]

3.3. Client Processing

[Look for DHCP, then try reverse]

4. Protocol

[JSON over HTTP or WebSocket]

4.1. Message Format

[Overall structure: Array of JSON objects with specified fields. MUST include a "type" field; Implementations MUST ignore messages with unknown types.]

[MIME media type: 'application/amp+json']

[For each message type: Direction (C2S or S2C) and fields; each field has specified type and mandatory / optional; mandatory array fields MUST NOT contain the empty array]

4.1.1. Registration

[Client->Server]

[Field: "token", contains identifier for client]

[Field: "contacts", contains array of URIs]

[Field: "location", contains "location-info" element from PIDF-LO]

[Field; "language", contains laguage tag]

[Client may repeat to update information]

[Empty update implies delete]

4.1.2. Advertisement

[Server->Client]

[Field: "contacts", contains array of URIs from which alerts will be sourced]

[Field: "token", contains an identifier that the client should use in future requests]

[Field: "certs", contains array of certificates for local alert authorities]

[Field: "public_keys", contains array of SPKI for local alert authorities]

[Field: "hash_values", contains array of hash values for ESCAPE verification]

[Field: "ttl", contains integer number of seconds for which this advertsiement is valid]

4.1.3. Refer

[Server->Client]

[Field: "to", contains URI of new AMP server that client should contact]

4.1.4. Alert

[Server->Client]

[Field: "alert_data", contains ESCAPE-encoded alert. ]

4.2. WebSocket Binding

[Subprotocol 'alert-metadata'; use 'text' bodies to exchange AMP messages]

[On connect, client SHOULD send registration, server SHOULD send advertisement]

4.3. HTTP Binding

[Request MUST be POST, response MUST be 200 unless an HTTP-layer error]

[Request SHOULD contain registration]

[Response SHOULD contain advertisement]

5. IANA Considerations

This document requires several registrations by IANA into existing registries, and creates a new registry of AMP message codes.

5.1. DHCP Option Code

[TODO]

5.2. NAPTR Service Tag

[TODO]

5.3. WebSocket Sub-Protocol

[TODO]

5.4. Media type application/amp+json

[TODO]

5.5. AMP Message Type Registry

[TODO]

6. Security Considerations

[This protocol runs over HTTP, so TLS is the security layer. Standard caveats about NAPTR / server-id / DNSSEC. ]

[Confidentiality: If this protocol can be intercepted, clients' private information might be exposed, e.g., contacts or location]

[Integrity: If this protocol can be modified, clients can be convinced to accept false alerts (advertisement), or denied alerts (registration), or get alerts for the wrong location (registration).]

7. Acknowledgements

[TODO]

8. References

8.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.P. and G. Randers-Pehrson, "GZIP file format specification version 4.3", RFC 1952, May 1996.
[RFC2045] Freed, N. and N.S. 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. 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.
[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.

8.2. Informative References

[I-D.ietf-atoca-requirements] Schulzrinne, H, Norreys, S, Rosen, B and H Tschofenig, "Requirements, Terminology and Framework for Exigent Communications", Internet-Draft draft-ietf-atoca-requirements-02, October 2011.

Author's Address

Richard Barnes BBN Technologies 9861 Broken Land Parkway Columbia, MD 21046 US Phone: +1 410 290 6169