One document matched: draft-gerdes-ace-a2a-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.22 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY SELF "[RFC-XXXX]">
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-gerdes-ace-a2a-00" category="info">

  <front>
    <title abbrev="dcaf-a2a">Managing the Authorization to Authorize in the Lifecycle of a Constrained Device</title>

    <author initials="S." surname="Gerdes" fullname="Stefanie Gerdes">
      <organization>Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63906</phone>
        <email>gerdes@tzi.org</email>
      </address>
    </author>

    <date year="2015" month="March" day="09"/>

    <area>Security</area>
    <workgroup>ACE Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>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.</t>

<t>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.</t>

<t>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.</t>

<t>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.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>As shown in <xref target="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) <xref target="I-D.gerdes-ace-dcaf-authorize"/>
defines 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.</t>

<t>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.</t>

<t>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.</t>

</section>
<section anchor="terminology" title="Terminology">

<t>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 <xref target="RFC2119"/>.</t>

<t><list style="symbols">
  <t>Readers should be familiar with the terminology introduced in
<xref target="I-D.gerdes-ace-actors"/></t>
</list></t>

</section>
<section anchor="authorization-to-authorize" title="Authorization to Authorize">

<t>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.</t>

<t>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.</t>

<t>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
Manager. The URI is stored in resource that we call AM-URI,
e.g. /am/uri.</t>

<t>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.</t>

</section>
<section anchor="AM_assign" title="Assigning a new Authorization Manager">

<t>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.</t>

<t>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.</t>

<t>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:</t>

<t><list style="symbols">
  <t>request a ticket from the former AM.</t>
  <t>use a preconfigured ticket.</t>
  <t>use a copy of the old AM-key to create the ticket.</t>
</list></t>

<t>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.</t>

<t>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.</t>

<t>If the client is not the new AM, the new K_AM MUST be transmitted
to the new AM and removed from the client.</t>

<!-- TODO: Example for message exchange -->

</section>
<section anchor="authorization-transitions-in-the-lifecycle-of-constrained-devices" title="Authorization Transitions in the Lifecycle of Constrained Devices">

<t>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
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.</t>

<t>Apart from the operation phase, mechanisms for
changing the authorization to authorize are needed in every phase of
the lifecycle. </t>

<section anchor="manufacturing" title="Manufacturing">

<t>In the manufacturing phase, the manufacturer can choose one of the
following options for the initial key provisioning:</t>

<t><list style="symbols">
  <t>Provisioning with AM service: K_AM is provisioned to the new device
and the manufacturer provides an Authorization Manager service.</t>
  <t>Provisioning only: K_AM is provisioned to the new device but the
manufacturer does not provide an Authorization Manager service.</t>
  <t>No provisioning: No K_AM is provisioned to the newly manufactured
device.</t>
</list></t>

<t>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.</t>

<t>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.</t>

<t>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.</t>

</section>
<section anchor="commissioning" title="Commissioning">

<t>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 <xref target="AM_assign"/>).</t>

<t>To assign a new Authorization Manager, the procedure described in
<xref target="AM_assign"/> is used.</t>

<!-- Resource Directories? -->

</section>
<section anchor="decommissioning" title="Decommissioning">

<t>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.</t>

<t>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.</t>

<t>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.</t>

<!-- TODO: how do we do this? -->

</section>
<section anchor="handover-and-maintenance" title="Handover and Maintenance">

<t>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.</t>

<t>The exchange of the AM consists of a decomissioning as described in
<xref target="decommissioning"/> followed by a commissioning as described in
<xref target="commissioning"/>. Before the decommissioning, one of the mechanisms
described in <xref target="AM_assign"/> for the commissioning MUST be used to
create an authorization ticket for assigning the new AM.</t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t><list style="symbols">
  <t>What do we do if the key for changing the AM is lost?</t>
  <t>K_AM must be protected. The entity that has K_AM is in control of the
constrained device.</t>
  <t>It might be difficult to protect a preconfigured K_AM.</t>
  <t>If the PSK is printed onto the device, everyone who has access to
the device can use it.</t>
  <t>If a new AM-key is transmitted this transmission must be protected
very well.</t>
</list></t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>None</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='RFC2119'>

<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      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.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>

<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>



<reference anchor='I-D.gerdes-ace-dcaf-authorize'>
<front>
<title>Delegated CoAP Authentication and Authorization Framework (DCAF)</title>

<author initials='S' surname='Gerdes' fullname='Stefanie Gerdes'>
    <organization />
</author>

<author initials='O' surname='Bergmann' fullname='Olaf Bergmann'>
    <organization />
</author>

<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
    <organization />
</author>

<date month='February' day='9' year='2015' />

<abstract><t>This specification defines a protocol for delegating client authentication and authorization in a constrained environment for establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes.  The protocol relies on DTLS to transfer authorization information and shared secrets for symmetric cryptography between entities in a constrained network.  A resource- constrained node can use this protocol to delegate authentication of communication peers and management of authorization information to a trusted host with less severe limitations regarding processing power and memory.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-gerdes-ace-dcaf-authorize-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-gerdes-ace-dcaf-authorize-01.txt' />
</reference>




    </references>

    <references title='Informative References'>





<reference anchor='I-D.gerdes-ace-actors'>
<front>
<title>Actors in the ACE Architecture</title>

<author initials='S' surname='Gerdes' fullname='Stefanie Gerdes'>
    <organization />
</author>

<date month='October' day='27' year='2014' />

<abstract><t>Constrained nodes are small 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.  Due to the limitations of the constrained nodes it is especially important to develop a light-weight security solution which is adjusted to the relevant security objectives of each participating party in this environment.  Necessary security measures must be identified and applied where needed.  In this document, the required security related tasks are identified as guidance for the development of authentication and authorization solutions for constrained environments.  Based on the tasks, an architecture is developed to represent the relationships between the logical functional entities involved.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-gerdes-ace-actors-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-gerdes-ace-actors-02.txt' />
<format type='PDF'
        target='http://www.ietf.org/internet-drafts/draft-gerdes-ace-actors-02.pdf' />
</reference>




    </references>



  </back>
</rfc>