[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
ACE Working Group                                              S. Gerdes
Internet-Draft                                   Universitaet Bremen TZI
Intended status: Informational                        September 11, 2015
Expires: March 14, 2016

     Managing the Authorization to Authorize in the Lifecycle of a
                           Constrained Device


   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

   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.

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 March 14, 2016                 [Page 1]

Internet-Draft                   ace-a2a                  September 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 March 14, 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.  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
       Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Manufacturing . . . . . . . . . . . . . . . . . . . . . .   5
     5.2.  Commissioning . . . . . . . . . . . . . . . . . . . . . .   6
     5.3.  Decommissioning . . . . . . . . . . . . . . . . . . . . .   6
     5.4.  Handover  . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.5.  Maintenance . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   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.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

Gerdes                   Expires March 14, 2016                 [Page 2]

Internet-Draft                   ace-a2a                  September 2015

   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.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

   o  Readers should be familiar with the concepts and terminology
      introduced in [I-D.ietf-ace-actors] and

3.  Authorization to Authorize

   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.

Gerdes                   Expires March 14, 2016                 [Page 3]

Internet-Draft                   ace-a2a                  September 2015

   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.

4.  Assigning a new Authorization Manager

   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

   o  request a ticket from the former AM.

   o  use a preconfigured 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.

5.  Authorization Transitions in the Lifecycle of Constrained Nodes

   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.

Gerdes                   Expires March 14, 2016                 [Page 4]

Internet-Draft                   ace-a2a                  September 2015

   Apart from the operation phase, mechanisms for changing the
   authorization to authorize are needed in every phase of the

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 node
      and the manufacturer provides an Authorization Manager service.

   o  Provisioning only: K_AM is provisioned to the new node but the
      manufacturer does not provide an Authorization Manager service.

   o  No provisioning: No K_AM is provisioned to the newly manufactured

   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.

Gerdes                   Expires March 14, 2016                 [Page 5]

Internet-Draft                   ace-a2a                  September 2015

5.2.  Commissioning

   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.

5.3.  Decommissioning

   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.

5.4.  Handover

   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.

5.5.  Maintenance

   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

Gerdes                   Expires March 14, 2016                 [Page 6]

Internet-Draft                   ace-a2a                  September 2015

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

   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


8.  References

8.1.  Normative References

              Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP
              Authentication and Authorization Framework (DCAF)", draft-
              gerdes-ace-dcaf-authorize-02 (work in progress), March

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,

8.2.  Informative References

              Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An
              architecture for authorization in constrained
              environments", draft-ietf-ace-actors-00 (work in
              progress), August 2015.

Author's Address

Gerdes                   Expires March 14, 2016                 [Page 7]

Internet-Draft                   ace-a2a                  September 2015

   Stefanie Gerdes
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359

   Phone: +49-421-218-63906
   Email: gerdes@tzi.org

Gerdes                   Expires March 14, 2016                 [Page 8]