One document matched: draft-gerdes-ace-a2a-00.txt
ACE Working Group S. Gerdes
Internet-Draft Universitaet Bremen TZI
Intended status: Informational March 09, 2015
Expires: September 10, 2015
Managing the Authorization to Authorize in the Lifecycle of a
Constrained Device
draft-gerdes-ace-a2a-00
Abstract
Constrained nodes are devices which are limited in terms of
processing power, memory, non-volatile storage and transmission
capacity. Due to these constraints, commonly used security protocols
are not easily applicable. Nevertheless, an authentication and
authorization solution is needed to ensure the security of these
devices.
During the lifecycle of a constrained device, responsibility for
managing authorization policies for the constrained device may change
several times. To ensure the security of the constrained devices,
the authorization to authorize must be transferred to the new
principal in a secure way.
The Delegated CoAP Authorization Framework (DCAF) specifies how
resource-constrained nodes can delegate defined authentication- and
authorization-related tasks to less-constrained devices called
Authorization Managers, thus limiting the hardware requirements of
the security solution for the constrained devices.
This document defines how DCAF can be used to manage the
Authorization Manager of a constrained device and introduces a
flexible authorization solution for the whole lifecycle of a
constrained device.
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
Gerdes Expires September 10, 2015 [Page 1]
Internet-Draft dcaf-a2a March 2015
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 September 10, 2015.
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Authorization to Authorize . . . . . . . . . . . . . . . . . 3
4. Assigning a new Authorization Manager . . . . . . . . . . . . 4
5. Authorization Transitions in the Lifecycle of Constrained
Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Manufacturing . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Commissioning . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Decommissioning . . . . . . . . . . . . . . . . . . . . . 6
5.4. Handover and Maintenance . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
As shown in [I-D.gerdes-ace-actors], constrained devices can benefit
from being closely coupled to a less constrained device, the
Authorization Manager (AM). The AM helps its constrained devices
with authentication and authorization tasks. The delegated CoAP
Authentication and Authorization Framework (DCAF)
[I-D.gerdes-ace-dcaf-authorize] defines the communication flow
between client, server and their respective Authorization Managers,
Gerdes Expires September 10, 2015 [Page 2]
Internet-Draft dcaf-a2a March 2015
thus relieving constrained nodes from managing keys for numerous
devices while ensuring that the constrained devices are able to
enforce the authorization policies of their principals.
Since the constrained devices strongly rely on their Authorization
Managers for security-related tasks, the connection between the
constrained device and its respective AM needs to be especially
protected. This is particularly difficult at transitions between
different phases in the lifecycle of a constrained device. These
transitions often comprise a change of the device ownership and
therefore might often entail that the principal that controls the
authorization policies changes. One way of transferring this
authorization to authorize is to change which Authorization Manager
is responsible for a constrained device.
This document defines how DCAF can be used to manage the
Authorization Manager of a constrained device and introduces a
flexible authorization solution for the whole lifecycle of a
constrained device.
2. Terminology
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].
o Readers should be familiar with the terminology introduced in
[I-D.gerdes-ace-actors]
3. Authorization to Authorize
AM helps its constrained device to determine the authorization of
another device, e.g. if it is allowed to access an item of interest
or to provide information about such an item. Some security-related
tasks must be conducted by the constrained device itself, such as
message authentication and the enforcement of authorization policies.
However, the information needed for these tasks are provided by the
AM which represents the principal's will to the constrained device.
Principals can easily configure the AM since it has the necessary
user interface. In particular, AM provides authorization information
to the constrained device: It is authorized to define authorizations.
The constrained device shares a symmetric key with its AM. We call
this key K_AM. The constrained device uses this key to determine if
the authorization information was provided by the AM.
K_AM is stored in a resource which we call AM-Key, e.g. /am/key. The
key belongs to a URI which is the address of the Authorization
Gerdes Expires September 10, 2015 [Page 3]
Internet-Draft dcaf-a2a March 2015
Manager. The URI is stored in resource that we call AM-URI, e.g.
/am/uri.
The AM-key resource needs special protection because the entity which
controls K_AM is in control of the constrained device. Therefore,
the AM-key resource MUST be access-protected and SHOULD be write-
only.
4. Assigning a new Authorization Manager
To assign a new AM to a constrained device, the AM-key resource must
be changed. In this case, the constrained device always acts as the
Server, even if it is generally used as a client. The client in this
communication SHOULD be the new AM.
To change the value of a resource representation, a ticket is needed.
DCAF tickets consist of two parts, the ticket face and the verifier.
While the client uses the verifier as a session key, the Server can
derive the session key from the ticket face and the AM-key.
To change the AM-key (/am/key) and AM-URI (/am/uri) resources, the
client needs a ticket that authorizes it to use PUT on these
resources. There are three possibilities for a client to get this
ticket:
o request a ticket from the former AM.
o use a preconfigured ticket.
o use a copy of the old AM-key to create the ticket.
With the help of the ticket, client and server establish a DTLS
session. The new K_AM and the URI of the new AM can then be securely
transmitted to the Server.
The new K_AM MUST NOT be disclosed to others. If the authorization
ticket is requested from the former AM, the client MUST NOT include
the new K_AM in the Access Request Message.
If the client is not the new AM, the new K_AM MUST be transmitted to
the new AM and removed from the client.
5. Authorization Transitions in the Lifecycle of Constrained Devices
The lifecycle of a constrained device consists of several phases.
The device is created in the manufacturing phase. Devices are then
sold to customers who introduce them to their networks during the
commissioning phase. In the operation phase, constrained devices
Gerdes Expires September 10, 2015 [Page 4]
Internet-Draft dcaf-a2a March 2015
fullfill their purpose in life, sometimes alternated with a
maintenance phase. Some devices are sold during their lifetime and
need to be decommissioned and recommissioned in the handover phase.
At the end of the device's lifecycle, the device is decommissioned in
the decommissioning phase.
Apart from the operation phase, mechanisms for changing the
authorization to authorize are needed in every phase of the
lifecycle.
5.1. Manufacturing
In the manufacturing phase, the manufacturer can choose one of the
following options for the initial key provisioning:
o Provisioning with AM service: K_AM is provisioned to the new
device and the manufacturer provides an Authorization Manager
service.
o Provisioning only: K_AM is provisioned to the new device but the
manufacturer does not provide an Authorization Manager service.
o No provisioning: No K_AM is provisioned to the newly manufactured
device.
In the provisioning with AM service case, the manufacturer provides
an own AM service. Future principals can use the AM service if they
don't want to maintain an own AM. The manufacturer sets the AM-URI
resource to the URI of the manufacturer's AM and writes the initial
K_AM into the AM-key resource. Additionally, K_AM is provided to the
Authorization Manager. Each constrained device SHOULD be provisioned
with an individual unique key.
In the provisioning only case, the manufacturer does not provide an
AM service. The AM-key resource is set to the initial K_AM. The AM-
URI resource is left empty. K_AM has to be made available to the new
principal, e.g. by encoding it into a QR code and printing it onto a
sheet of paper which is delivered with the device, or onto the device
itself. K_AM SHOULD be kept secret.
In the no provisioning case, the AM-key resource is not initialized
and MUST be unprotected. The new principal will then be able to
write an AM-key into this resource without the need for an
authorization ticket.
Gerdes Expires September 10, 2015 [Page 5]
Internet-Draft dcaf-a2a March 2015
5.2. Commissioning
In the commissioning phase, the principal of the device has changed.
The new principal needs to be able to take over the control over the
device by defining authorization policies. To achieve this,
principals will either use the Authorization Manager service of the
manufacturer (if available) or need to assign a new Authorization
Manager to the device (see also Section 4).
To assign a new Authorization Manager, the procedure described in
Section 4 is used.
5.3. Decommissioning
If a device is discarded or sold, the principal of the device
changes. To make sure that nobody who gets hold of the device
afterwards is able to misuse it, permissions for the device must be
revoked.
The principal removes authorizations for the constrained device from
the AM. Since the AM is used to negotiate tickets for new
connections with other devices, the decommissioned device will not be
able to request new connections afterwards.
Already existing tickets and session keys have to be removed from the
decommissioned device. In particular, for Servers the ticket faces
and derived session keys need to be erased, for Clients the Verifiers
must be deleted.
5.4. Handover and Maintenance
During the lifecycle of a constrained device, Authorization Managers
sometimes need to be exchanged for maintenance reasons or because the
device is sold. In both cases, the relationship between the former
AM and the constrained device must be broken.
The exchange of the AM consists of a decomissioning as described in
Section 5.3 followed by a commissioning as described in Section 5.2.
Before the decommissioning, one of the mechanisms described in
Section 4 for the commissioning MUST be used to create an
authorization ticket for assigning the new AM.
6. Security Considerations
o What do we do if the key for changing the AM is lost?
o K_AM must be protected. The entity that has K_AM is in control of
the constrained device.
Gerdes Expires September 10, 2015 [Page 6]
Internet-Draft dcaf-a2a March 2015
o It might be difficult to protect a preconfigured K_AM.
o If the PSK is printed onto the device, everyone who has access to
the device can use it.
o If a new AM-key is transmitted this transmission must be protected
very well.
7. IANA Considerations
None
8. References
8.1. Normative References
[I-D.gerdes-ace-dcaf-authorize]
Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP
Authentication and Authorization Framework (DCAF)", draft-
gerdes-ace-dcaf-authorize-01 (work in progress), February
2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.gerdes-ace-actors]
Gerdes, S., "Actors in the ACE Architecture", draft-
gerdes-ace-actors-02 (work in progress), October 2014.
Author's Address
Stefanie Gerdes
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63906
Email: gerdes@tzi.org
Gerdes Expires September 10, 2015 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 02:44:05 |