Public Safety Use Case
draft-rahman-ace-public-safety-use-case-00

Abstract

A public safety use case is proposed for consideration by the ACE WG.

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 January 7, 2016.

Copyright Notice

Copyright (c) 2015 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. Terminology and Conventions
• 2. Background
• 3. Public Safety Use Case
• 4. Authorization Problem Summary
• 5. Acknowledgements
• 6. IANA Considerations
• 7. Security Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Terminology and Conventions

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].

This document assumes readers are familiar with the terms and concepts that are used in [RFC7252] and [I-D.ietf-ace-usecases].

2. Background

The ACE WG, as per their charter, is in the process of defining use cases to drive the specification of standardized solutions for authentication and authorization to enable authorized access (Get, Put, Post, Delete) to resources identified by a URI and hosted on a resource server in constrained environments. As a starting point, the WG will assume that access to resources at a resource server by a client device takes place using CoAP and is protected by DTLS ([RFC7252]). Both resource server and client may be constrained. This access will be mediated by an authorization server, which is not considered to be constrained.

3. Public Safety Use Case

A Fire Department requires that as part of the building safety code, that the building have sensors that sense the level of smoke, heat, Etc., when a fire breaks out. These sensors report metrics which are then used by a back-end server to map safe areas and un-safe areas within a building and also possibly the structural integrity of the building before fire-fighters may enter it. Sensors may also be used to track where human/animal activity is within the building. This will allow people stuck within the building to be guided to safer areas and suggest possible actions that they make take (e.g. using a client application on their phones, or loudspeaker directions) in order to bring them to safety. In certain cases, other organizations such as the Police, Ambulance, and federal organizations are also involved and therefore the co-ordination of tasks between the various entities have to be carried out using efficient messaging and authorization mechanisms.

4. Authorization Problem Summary

1. The principal wants to ensure that only authorized clients can read data from sensors and send commands to the actuators.

2. The principal wants to be able to grant access rights dynamically when needed. This may be triggered where the Principal may be human or machine (server/cloud system).

3. The principal wants to ensure the authenticity of the data originating from the sensors (authenticating the originator of data).

4. The principal wants to ensure the Integrity of the received data; also wants to verify the Integrity of the sensor since in the case of fire, the sensor may itself be damaged, therefore will have to rely on sensors from different rooms.

5. The principal wants to ensure that data sent to the actuators are Integrity protected.

6. The principal wants to ensure that extremely time-sensitive operations have to be carried out in a quick manner.

7. The principal wants to ensure the ability to prove that an entity (e.g. police or fire chief) that issued a message had indeed issued the message by using non-repudiation mechanisms.

8. The principal wants to ensure that all the messaging and data involved during a crisis is audit-able in a transparent manner.

5. Acknowledgements

TBD.

6. IANA Considerations

This memo includes no request to IANA.

7. Security Considerations

The entire draft is regarding a security use case related to authentication and authorization for constrained environments.

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses