| ACE Working Group | S. Gerdes |
| Internet-Draft | Universität Bremen TZI |
| Intended status: Informational | September 11, 2015 |
| Expires: March 14, 2016 |
Managing the Authorization to Authorize in the Lifecycle of a Constrained Device
draft-gerdes-ace-a2a-01
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.
Resource-constrained nodes benefit from delegating 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 security relationships between constrained nodes and their Authorization Managers can be established and managed in a RESTful way, thus providing for a flexible authorization solution for the whole lifecycle of a constrained node.
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 March 14, 2016.
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.
As shown in [I-D.ietf-ace-actors], constrained nodes can benefit from being closely coupled to a less constrained node called Authorization Server or Authorization Manager (AM). The AM helps its constrained node with authentication and authorization tasks. Authorization solutions such as the delegated CoAP Authentication and Authorization Framework (DCAF) [I-D.gerdes-ace-dcaf-authorize] define the communication flow between client, server and their respective Authorization Managers, 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 the security relationship between a constrained node and its Authorization Manager can be managed in a RESTful way, thus providing for a flexible authorization solution for the whole lifecycle of a constrained device.
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].
The Authorization Manager helps its constrained node to determine the authorization of another node, e.g. if it is allowed to access an item of interest or to provide information about such an item. Principals can easily configure authorization information on the AM since it has the necessary user interface. AM provides the authorization information to the constrained node: It is authorized to define authorizations.
The constrained node needs keying material to determine if the authorization information was really provided by its AM. We call this keying material K_AM. Depending on the authorization solution, symmetric or asymmetric keys can be used. For symmetric solutions, the constrained node and the AM share a key. For asymmetric solutions, K_AM is AM’s public key.
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 AM. 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 node. Therefore, the AM-key resource MUST be access-protected and SHOULD be write-only.
To assign a new AM to a constrained node, the AM-key resource must be changed. In this case, the constrained node always acts as the server, even if it is otherwise 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. 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:
With the help of the ticket, the constrained device can determine that request is authorized. In DCAF, it can additionally be used to establish a DTLS session between client and server. 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.
The lifecycle of a constrained node can be roughly divided into six 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 nodes fullfill their purpose in life, sometimes alternated with a maintenance phase. Some nodes are sold during their lifetime and need to be decommissioned and recommissioned in the handover phase. At the end of the node’s lifecycle, the node 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.
In the manufacturing phase, the manufacturer can choose one of the following options for the initial key provisioning:
In the provisioning with AM service case, the manufacturer provides an own AM service. Future principals can use the AM service to request a ticket for their own AM or might even continue to use the manufacturer’s AM if they don’t want to maintain their own. The node’s AM-URI resource is set to the URI of the manufacturer’s AM. Additionally, the manufacturer configures the K_AM keying material on the AM and the constrained node. Depending on the used solution shared symmetric keys or asymmetric key pairs are used. For symmetric solutions, a shared secret must be generated and provided to constrained node and AM. Each constrained node SHOULD be provisioned with an individual unique key. For asymmetric solutions, key pairs must be generated on the constrained node and the AM. The AM’s public key is stored as K_AM in the AM-key resource.
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.
In the commissioning phase, the principal of the node has changed. The new principal needs to be able to take over the control over the node 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 node (see also Section 4).
To assign a new Authorization Manager, the procedure described in Section 4 is used.
The constrained node MUST end all existing communications and delete all Tickets that were issued by the former AM.
If a device is discarded or sold, the principal of the node changes. To make sure that nobody who gets hold of the device afterwards is able to misuse it, permissions for the node must be revoked.
The constrained node must be deregistered from the AM. AM MUST NOT issue any new tickets for the constrained node and SHOULD revoke tickets on communication partners of this node.
Already existing tickets and session keys have to be removed from the decommissioned node.
A change of ownership of a node often entails that the relationship between the former AM and the constrained node must be canceled.
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.
During the lifecycle of a constrained node, Authorization Managers sometimes need to be exchanged, e.g. because they are replaced by a newer model. In this case, the former AM should issue a ticket for the new AM before it is decommissioned. The AM-Key SHOULD be deleted from the old AS to prevent it from issuing new tickets before the AM-Key is changed. Old tickets issued by the AM do not need to be revoked.
None
| [I-D.gerdes-ace-dcaf-authorize] | Gerdes, S., Bergmann, O. and C. Bormann, "Delegated CoAP Authentication and Authorization Framework (DCAF)", Internet-Draft draft-gerdes-ace-dcaf-authorize-02, March 2015. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [I-D.ietf-ace-actors] | Gerdes, S., Seitz, L., Selander, G. and C. Bormann, "An architecture for authorization in constrained environments", Internet-Draft draft-ietf-ace-actors-00, August 2015. |