Internet DRAFT - draft-rahman-ace-public-safety-use-case
draft-rahman-ace-public-safety-use-case
ACE WG A. Rahman
Internet-Draft C. Wang
Intended status: Informational V. Choyi
Expires: January 29, 2016 InterDigital Communications, LLC
July 28, 2015
Public Safety Use Case
draft-rahman-ace-public-safety-use-case-01
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 29, 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.
Rahman, et al. Expires January 29, 2016 [Page 1]
Internet-Draft Public Safety Use Case July 2015
Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Public Safety Use Case . . . . . . . . . . . . . . . . . . . 2
4. Authorization Problem Summary . . . . . . . . . . . . . . . . 3
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
7. Security Considerations . . . . . . . . . . . . . . . . . . . 3
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
8.1. Normative References . . . . . . . . . . . . . . . . . . 4
8.2. Informative References . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4
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
Rahman, et al. Expires January 29, 2016 [Page 2]
Internet-Draft Public Safety Use Case July 2015
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.
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 (authenticating the sender of the message).
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.
Rahman, et al. Expires January 29, 2016 [Page 3]
Internet-Draft Public Safety Use Case July 2015
8. References
8.1. Normative References
[I-D.ietf-ace-usecases]
Seitz, L., Gerdes, S., Selander, G., Mani, M., and S.
Kumar, "ACE use cases", draft-ietf-ace-usecases-04 (work
in progress), June 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<http://www.rfc-editor.org/info/rfc6690>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
the Constrained Application Protocol (CoAP)", RFC 7390,
DOI 10.17487/RFC7390, October 2014,
<http://www.rfc-editor.org/info/rfc7390>.
Authors' Addresses
Akbar Rahman
InterDigital Communications, LLC
Email: akbar.rahman@interdigital.com
Chonggang Wang
InterDigital Communications, LLC
Email: chonggang.wang@interdigital.com
Vinod Choyi
InterDigital Communications, LLC
Email: vinod.choyi@interdigital.com
Rahman, et al. Expires January 29, 2016 [Page 4]
