One document matched: draft-gerdes-ace-actors-03.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-actors-03" category="info">
<front>
<title abbrev="ace-actors">Actors in the ACE Architecture</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 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.</t>
<t>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.</t>
<t>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>
<middle>
<section anchor="introduction" title="Introduction">
<t>Constrained nodes are small devices with limited abilities which in
many cases are made to fulfill a single simple task. They have limited
hardware resources such as processing power, memory, non-volatile storage and
transmission capacity and additionally in most cases do not have user
interfaces and displays. Due to these constraints, commonly used
security protocols are not always easily applicable.</t>
<t>Constrained nodes are expected to be integrated in all aspects of
everyday life and thus will be entrusted with vast amounts of
data. Without appropriate security mechanisms attackers might gain
control over things relevant to our lives. Authentication and
authorization mechanisms are therefore
prerequisites for a secure Internet of Things.</t>
<t>The limitations of the constrained nodes ask for security mechanisms
which take the special characteristics of constrained environments
into account. Therefore, it is crucial to identify the
tasks which must be performed to meet the security requirements in
constrained scenarios. Moreover, these tasks need to be assigned to logical
functional entities which perform the tasks: the actors in the
architecture. Thus, relations between the actors and requirements for
protocols can be identified.</t>
<t>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>
<section anchor="terminology" title="Terminology">
<t>Readers are required to be familiar with the terms and concepts
defined in <xref target="RFC4949"/>. In addition,
this document uses the following terminology:</t>
<t><list style="hanging">
<t hangText='Resource (R):'>
an item of interest, which is represented through an interface. It
might contain sensor or actuator
values or other information.</t>
<t hangText='Constrained node:'>
a constrained device in the sense of <xref target="RFC7228"/>.</t>
<t hangText='Actor:'>
A logical functional entity that performs one or more
tasks. Depending on the tasks an actor must perform, the device that
contains the actor may need to have certain system resources
available. Multiple actors may share, i.e. be present within, a device
or even a piece of software.</t>
<t hangText='Server (S):'>
An entity which hosts and represents a Resource.</t>
<t hangText='Client (C):'>
An entity which attempts to access a resource on a Server.</t>
<t hangText='Resource Overseeing Principal (ROP):'>
The principal that is in charge of the resource and controls its access permissions.</t>
<t hangText='Client Overseeing Principal (COP):'>
The principal that is in charge of the Client and controls permissions
concerning authorized representations of a Resource.</t>
<t hangText='Server Authorization Manager (SAM):'>
An entity that prepares and endorses authentication and
authorization data for a Server.</t>
<t hangText='Client Authorization Manager (CAM):'>
An entity that prepares and endorses authentication and
authorization data for a Client.</t>
<t hangText='Attribute Binding Authority:'>
An entity that is authorized to validate claims about an entity.</t>
</list></t>
</section>
</section>
<section anchor="ps" title="Problem Statement">
<t>The scenario this document addresses can be summarized as
follows:</t>
<t><list style="symbols">
<t>C wants to access R on a S.</t>
<t>A priori, C and S do not necessarily know each other and have no security
relationship.</t>
<t>C and / or S are constrained.</t>
</list></t>
<figure title="Basic Scenario" anchor="figbasic"><artwork><![CDATA[
------- -------
| C | -- requests resource ---> | S |
------- <-- provides resource--- -------
]]></artwork></figure>
<!-- graphic: request.png -->
<t>There are some security requirements for this scenario including one or more of:</t>
<t><list style="symbols">
<t>Rq0.1: No unauthorized entity has access to (or otherwise
gains knowledge of) R.</t>
<t>Rq0.2: C is exchanging status updates of a resource only with
authorized resources. (When C attempts to access R, that access
reaches an authorized R).</t>
</list></t>
<t>Rq0.1 requires authorization on the server side while Rq0.2 requires
authorization on the client side.</t>
</section>
<section anchor="security_objectives" title="Security Objectives">
<t>The security objectives that can be
addressed by an authorization solution are confidentiality and
integrity. Availability cannot be achieved by authorization
solutions. However, misconfigured or wrongly designed authorization
solutions can result in availability breaches: Users might no longer
be able to use data and services as they are supposed to.</t>
<t>Authentication mechanisms can achieve additional security objectives
such as non-repudiation and accountability. They are not related to
authorization and thus are not in scope of this draft, but still should
be considered by Authenticated Authorization solutions.
Non-repudiation and accountability may require authentication on
device level, if it is necessary to determine which device performed an
action. In other cases it may be more important to find out who is
responsible for the device’s actions.</t>
<t>The importance of a security objective depends on the application the
authorization mechanism is used for. <xref target="I-D.ietf-ace-usecases"/>
indicates that security objectives differ for the various constrained
environment use cases.</t>
<t>In many cases, one participating party might have different security
objectives than the other. However, to achieve a security objective,
both parties must participate in providing a solution. E.g., if COP
requires the integrity of sensor value representations S is hosting,
Both C and S need to integrity-protect the transmitted data. Moreover, S needs
to protect the access to the sensor representation to prevent
unauthorized users to manipulate the sensor values.</t>
</section>
<section anchor="authentication-and-authorization" title="Authentication and Authorization">
<t>Authorization solutions aim at protecting the access to items of
interest, e.g. hardware or software resources or data: They enable the
principal of such a resource to control who can access it and how.</t>
<t>To determine if an entity is authorized to access a resource, an
authentication mechanism is needed. According to the Internet
Security Glossary <xref target="RFC4949"/>, authentication is “the process of
verifying a claim that a system entity or system resource has a
certain attribute value.” Examples for attribute values are the ID of
a device, the type of the device or the name of its owner.</t>
<t>The security objectives the authorization mechanism
aims at can only be achieved if the authentication and the
authorization mechanism work together correctly. We use the term
<spanx style="emph">authenticated authorization</spanx> to refer to a synthesis of mechanism for
authentication and authorization.</t>
<t>If used for authorization, the authenticated attributes must be
meaningful for the purpose of the authorization, i.e. the
authorization policy grants access permissions based on these
attributes. If the authorization policy assigns permissions to
an individual entity, the authenticated attributes must be suitable to
uniquely identify this entity.</t>
<t>In scenarios where devices are communicating autonomously there is
less need to uniquely identify an individual device. For a
principal, the fact that a device belongs to a certain company or that
it has a specific type (e.g. light bulb) is likely more important than
that it has a unique identifier.</t>
<t>Resource and device overseeing principals need to decide about the required level of
granularity for the authorization, ranging from <spanx style="emph">device
authorization</spanx> over <spanx style="emph">owner authorization</spanx> to <spanx style="emph">binary
authorization</spanx> and <spanx style="emph">unrestricted authorization</spanx>. In the first case
different access permissions are
granted to individual devices while in the second case individual
owners are authorized. If binary authorization is used, all
authenticated entities have the same access permissions. Unrestricted
authorization for an item of interest means that no authorization
mechanism is used (not even by authentication) and all entities are able to
access the item as they see fit. More
fine-grained authorization does not necessarily provide more
security. Resource and device overseeing principals need to consider that an entity should
only be granted the permissions it really needs to ensure the
confidentiality and integrity of resources.</t>
<t>For all cases where an authorization solution is needed (all but
Unrestricted Authorization), the authorizing party needs to be able to
authenticate the party that is to be authorized. Authentication is
therefore required for messages that contain representations of an
accessed item. More precisely, the authorizing party needs to make
sure that the receiver of a message containing a representation, and
the sender of a message containing a representation are authorized to
receive and send this message, respectively. To achieve this, the
integrity of these messages is required: Authenticity cannot be
assured if it is possible for an attacker to modify the message during
transmission.</t>
<t>In some cases, only one side (only the client side or only the server
side) requires the integrity and / or confidentiality of a resource
value. In these cases, principals may decide to use binary
authorization which can be achieved by an authentication mechanism or
even unrestricted authorization where no authentication mechanism is
required. However, as indicated in <xref target="security_objectives"/>, the
security objectives of both sides must be considered. The security
objectives of one side can often only be achieved with the help of the
other side. E.g., if the server requires the confidentiality of a
resource representation, the client must make sure that it does not
send resource updates to parties other than the server. Therefore, the
client must at least use binary authorization.</t>
<!-- Validate that an entity has certain attributes which entitle it to
access a resource. -->
</section>
<section anchor="m2m" title="Autonomous Communication">
<t>The use cases defined in <xref target="I-D.ietf-ace-usecases"/> demonstrate that
constrained devices are often used for scenarios where their
principals are not present at the time of the communication. Moreover,
these devices often do not have any user interfaces or displays. Even
if the principals are present at the time of access, they may not be
able to communicate directly with the device. The devices therefore
need to be able to communicate autonomously. In some scenarios there
is an active user at one endpoint of the communication. Other
scenarios ask for true machine to machine (M2M) communication.</t>
<t>To achieve the principals’ security objectives, the devices must be
enabled to enforce the security policies of their principals.</t>
</section>
<section anchor="task_overview" title="Tasks">
<t>This section gives an overview of the tasks which must be performed in
the given scenario (see <xref target="ps"/>) to meet the security requirements.</t>
<t>As described in the problem statement, either C or S or both of them
are constrained. Therefore tasks which must be conducted by either C
or S must be performable by constrained nodes.</t>
<!-- TODO: owners don't necessarily want both Rq0.1 and Rq0.2 -->
<section anchor="basic-scenario-tasks" title="Basic Scenario Tasks">
<t>This document does not assume a specific solution. We assume however,
that at least the following information is exchanged between the
client and the server:</t>
<t><list style="symbols">
<t>C transmits to S which resource it requests to access, the kind of
action it wants to perform on the resource, and the parameters
needed for the action.</t>
<t>S transmits to C the result of the attempted access.</t>
</list></t>
</section>
<section anchor="security-related-tasks" title="Security-Related Tasks">
<t>The reason for the communication is that C wants S to process some
information. S’ reaction to C’s access request might be processed by
C. The reason for using an authorization solution is to validate that
the entity that sent the information used for processing is authorized
to provide it.</t>
<t>To validate if a sender is authorized to send a received piece of
information, the receiver must determine the sender’s
authorization. Correspondingly, to validate if a receiver is allowed
to receive a message, the sender must determine its
authorization. This can only be achieved with the help of an
authentication mechanism.</t>
</section>
<section anchor="authn_tasks" title="Authentication-Related Tasks">
<t>Several steps must be conducted for authenticating certain attributes
of an entity and validating the authenticity of an information:</t>
<t><list style="numbers">
<t>Attribute binding: The attribute that shall be verifiable must be
bound to a verifier,
e.g. a key. To achieve this, an entity that is authorized to conduct the
attribute binding, the attribute binding authority, checks if an
entity actually has the attributes it claims to have and then
binds them to a verifier. The binding authority must provide some
kind of endorsement information which enables other entities to
validate this binding.</t>
</list></t>
<t>Note: The attribute binding can be conducted using either symmetric or
asymmetric cryptography.</t>
<t><list style="numbers">
<t>Verifier validation: The entity that wants to authenticate the
source of an information checks the attribute-verifier-binding
using the endorsement provided by the attribute binding authority.</t>
<t>Authentication: The verifier is used for authenticating the source
of a data item, i.e. it is checked whether the data item is bound
to the verifier. Thus the attributes of the source can be determined.</t>
</list></t>
<t>Step 1 is addressed in <xref target="claim_val"/>. After the first step is
conducted, step 2 and step 3 can be performed when needed. They must
be performed together and thus are examined together as well. <!--
{{val_endorse}} introduces the tasks for step 2. --> Tasks for step 2
and 3 are Information authenticity (see <xref target="inf_authn"/>) and secure
communication (see <xref target="secure_comm"/>).</t>
</section>
<section anchor="authz_tasks" title="Authorization-Related Tasks">
<t>Several steps must be conducted for explicit authorization:</t>
<t><list style="numbers">
<t>Configuration of authorization information: The respective principals
(COP and ROP) must configure the authorization information according
to their authorization policy. An authorization information must
contain one or more permissions and the attribute an entity must
have to apply to this authorization. </t>
<t>Obtaining authorization information: Authorization information
must be made available to the entity which enforces the
authorization.</t>
<t>Authorization validation: The authorization of an entity with
certain attributes must be confirmed by applying the request in
conjunction with authenticated attributes to the policy provided
by the authorization information.</t>
<t>Authorization enforcement: According to the result of the
authorization validation the access to a resource is granted or
denied.</t>
</list></t>
<t>Tasks for step 1 are defined in <xref target="config_authz"/>. <xref target="obtain_authz"/>
addresses step 2. After step 1 and step 2 are conducted, step 3 and
step 4 can be performed when needed. Step 3 and step 4 must be
performed together and thus are examined together. <xref target="authz_val"/>
introduces tasks for these steps.</t>
</section>
</section>
<section anchor="actors" title="Actors">
<t>This section describes the various actors in the architecture. An
actor consists of a set of tasks and additionally has an security
domain (client domain or server domain) and a level (constrained,
principal, less-constrained). Tasks are assigned to actors according
to their security domain and required level.</t>
<t>Note: Actors are a concept to understand the security requirements for
constrained devices. The architecture of an actual solution might
differ as long as the security requirements that derive from the
relationship between the identified actors are considered. Several actors
might share a single device or even be combined in a single piece of software.
Interfaces between actors may be realized as protocols or be internal
to such a piece of software.
<!-- TODO improve description --></t>
<t>The concept of actors is used to assign the tasks defined in <xref target="tasks"/>
to logical functional entities.</t>
<section anchor="cla" title="Constrained Level Actors">
<t>As described in the problem statement (see <xref target="ps"/>), either C or S or both of
them may be located on a constrained node. We therefore define that C
and S must be able to perform their tasks even if they are located on
a constrained node. Thus, C and S are considered to be Constrained
Level Actors.</t>
<t>C performs the following tasks:</t>
<t><list style="symbols">
<t>Negotiate means for secure communication (Task TSecureComm, see
<xref target="secure_comm"/>).</t>
<t>Validate that an entity is an authorized source for R (Task
TValSourceAuthz, see <xref target="authz_val"/>).</t>
<t>Securely transmit an access request (Task TSendReq, see <xref target="send_info"/>).</t>
<t>Validate that the response to an access request is authentic (Task
TAuthnResp, see <xref target="inf_authn"/>).</t>
<t>Process the response to an access request (Task TProcResp, see
<xref target="proc_info"/>).</t>
</list></t>
<t>S performs the following tasks:</t>
<t><list style="symbols">
<t>Negotiate means for secure communication (Task TSecureComm, see
<xref target="secure_comm"/>).</t>
<t>Validate the authenticity of an access request (Task TAuthnReq, see
<xref target="inf_authn"/>).</t>
<t>Validate the authorization of the requester to access the requested
resource as requested (Task TValAccessAuthZ, see <xref target="authz_val"/>).</t>
<t>Process an access request (Task TProcReq, see <xref target="proc_info"/>).</t>
<t>Securely transmit a response to an access request (Task
TSendResp, see <xref target="send_info"/>).</t>
</list></t>
<t>R is an item of interest such as a sensor or actuator value. R is
considered to be part of S and not a separate actor. The device
on which S is located might
contain several resources of different Resource Overseeing Principals. For
simplicity of exposition, these resources are described as if they had
separate S.</t>
<t>As C and S do not necessarily know each other they might belong to
different security domains.</t>
<!-- Graphic: constrained_level_small.png -->
<figure title="Constrained Level Actors" anchor="figcl"><artwork><![CDATA[
------- -------
| C | -- requests resource ---> | S | Constrained Level
------- <-- provides resource--- -------
]]></artwork></figure>
</section>
<section anchor="principal-level-actors" title="Principal Level Actors">
<t>Our objective is that C and S are under control of principals in the physical world, the Client Overseeing Principal (COP)
and the Resource Overseeing Principal (ROP) respectively. The principals decide about the
security policies of their respective devices and belong to the same
security domain.</t>
<t>COP is in charge of C, i.e. COP specifies security policies for C,
e.g. with whom C is allowed to communicate. By definition, C and COP
belong to the same security domain.</t>
<t>COP must fulfill the following task:</t>
<t><list style="symbols">
<t>Configure for C authorization information for sources for R (Task
TConfigSourceAuthz, see <xref target="config_authz"/>).</t>
</list></t>
<t>ROP is in charge of R and S. ROP specifies authorization policies for R
and decides with whom S is allowed to communicate. By definition, R, S and ROP
belong to the same security domain.</t>
<t>ROP must fulfill the following task:</t>
<t><list style="symbols">
<t>Configure for S authorization information for accessing R (Task
TConfigAccessAuthz, see <xref target="config_authz"/>).</t>
</list></t>
<!-- nicht Graphic: ownersinchargeofconstr.png -->
<!-- sondern security_domains_owners.png -->
<figure title="Constrained Level Actors and Principal Level Actors" anchor="figclandpl"><artwork><![CDATA[
------- -------
| COP | | ROP | Principal Level
------- -------
| |
in charge of in charge of
| |
V V
------- -------
| C | -- requests resource ---> | S | Constrained Level
------- <-- provides resource--- -------
]]></artwork></figure>
</section>
<section anchor="lcl" title="Less-Constrained Level Actors">
<t>Constrained level actors
can only fulfill a limited number of tasks and may not have network
connectivity all the time. To relieve them from
having to manage keys for numerous devices and conducting
computationally intensive tasks, another complexity level for actors is
introduced. An actor on the less-constrained level belongs to the
same security domain as its respective constrained level actor. They
also have the same principal.</t>
<!-- TODO: verdeutlichen, wieso wir CAM UND SAM brauchen: Security
domains erklaeren -->
<t>The Client Authorization Manager (CAM) belongs to the same security domain as
C and COP. CAM acts on behalf of COP. It assists C in authenticating S
and determining if S is an authorized source for R. CAM can do that
because for C, CAM is the authority for claims about S.</t>
<t>CAM performs the following tasks:</t>
<t><list style="symbols">
<t>Validate on the client side that an entity has certain attributes
(Task TValSourceAttr, see <xref target="claim_val"/>).</t>
<t>Obtain authorization information about an entity from C’s principal and
provide it to C. (Task TObtainSourceAuthz, see <xref target="obtain_authz"/>).</t>
<t>Negotiate means for secure communication to communicate with C
(Task TSecureComm, see <xref target="secure_comm"/>).</t>
</list></t>
<t>The Server Authorization Manager (SAM) belongs to the same security domain as
R, S and ROP. SAM acts on behalf of ROP. It supports S by
authenticating C and determining C’s permissions on R. SAM can do that
because for S, SAM is the authority for claims about C.</t>
<t>SAM performs the following tasks:</t>
<t><list style="symbols">
<t>Validate on the server side that an entity has certain attributes
(Task TValReqAttr, see <xref target="claim_val"/>).</t>
<t>Obtain authorization information about an entity from S’ principal and
provide it to S (Task TObtainAccessAuthz, see <xref target="obtain_authz"/>).</t>
<t>Negotiate means for secure communication to communicate with S
(Task TSecureComm, see <xref target="secure_comm"/>).</t>
</list></t>
<!-- Another actor on the less-constrained level is the Authentication -->
<!-- Authority (AA). AA has the authority to claim that certain attributes -->
<!-- (e.g. a name) belong to a certain verifier (e.g. a key). Entities in -->
<!-- CO's security domain believe AA's claims about entities in RO's -->
<!-- security domain. Entities in RO's security domain believe AA's claims -->
<!-- about entities in CO's security domain. AA might not be a device or a -->
<!-- piece of software. Someone has to check if the attribute belongs to -->
<!-- the verifier. Either I check it myself or someone else checks it. -->
<!-- Graphic: eierlegendewollmilchsau2.png -->
<figure title="Overview of all Complexity Levels" anchor="figalllevels"><artwork><![CDATA[
------- -------
| COP | | ROP | Principal Level
------- -------
| |
in charge of in charge of
| |
V V
---------- -----------
| CAM | <- AuthN and AuthZ -> | SAM | Less-Constrained Level
---------- -----------
| |
authentication authentication
and authorization and authorization
support support
| |
V V
------- -------
| C | -- requests resource ---> | S | Constrained Level
------- <-- provides resource -- -------
]]></artwork></figure>
<t>For more detailed graphics please consult the PDF version.</t>
</section>
</section>
<section anchor="protocol-requirements" title="Protocol Requirements">
<!-- Namen fuer die unterschiedlichen Verbindungen. -->
<t>Devices on the less-constrained level potentially are more powerful than
constrained level devices in terms of processing power, memory,
non-volatile storage. This results in different requirements for the
protocols used on these levels.</t>
<section anchor="constrained-level-protocols" title="Constrained Level Protocols">
<t>A protocol is considered to be on the constrained level if it is used
between the actors C and S which are considered to be constrained
(see <xref target="cla"/>). C and S might not belong to the same security
domain. Therefore, constrained level protocols are required to work
between different security domains.</t>
<!-- graphic: tasks_cl.png -->
<figure title="Constrained Level Tasks" anchor="figcltasks"><artwork><![CDATA[
]]></artwork></figure>
<t>Commonly used Internet protocols can not in every case be applied to
constrained environments. In some cases, tweaking and profiling is
required. In other cases it is beneficial to define new protocols
which were designed with the special characteristics of constrained
environments in mind.</t>
<t>On the constrained level, protocols must be used which address the
specific requirements of constrained environments. The Constrained
Application Protocol (CoAP) <xref target="RFC7252"/> should be used as
transfer protocol if possible. CoAP defines a security binding to
Datagram Transport Layer Security Protocol (DTLS) <xref target="RFC6347"/>. Thus,
DTLS should be used for channel security.</t>
<t>Constrained devices have only limited storage space and thus cannot
store large numbers of keys. This is especially important because
constrained networks are expected to consist of thousands of
nodes. Protocols on the constrained level should keep this limitation
in mind.</t>
<section anchor="cross-level-support-protocols" title="Cross Level Support Protocols">
<t>Protocols which operate between a constrained device on one side and
the corresponding less constrained device on the other are considered
to be (cross level) support protocols. Protocols used between C and CAM
or S and SAM are therefore support protocols.</t>
<t>Support protocols must consider the limitations of their constrained
endpoint and therefore belong to the constrained level protocols.</t>
</section>
</section>
<section anchor="less-constrained-level-protocols" title="Less-Constrained Level Protocols">
<t>A protocol is considered to be on the less-constrained level if it is
used between the actors CAM and SAM. CAM and SAM might belong to
different security domains.</t>
<t>On the less-constrained level, HTTP <xref target="RFC7230"/> and Transport Layer
Security (TLS) <xref target="RFC5246"/> can be used alongside or instead of CoAP and
DTLS. Moreover, existing security solutions for authentication and
authorization such as the Web Authorization Protocol (OAuth)
<xref target="RFC6749"/> and Kerberos <xref target="RFC4120"/> can likely be used without
modifications and there are no limitations for the use of a Public Key
Infrastructure (PKI).</t>
<!-- graphic: tasks_lcl.png -->
<figure title="Less-constrained Level Tasks" anchor="figlcltasks"><artwork><![CDATA[
]]></artwork></figure>
<!-- # Examples -->
<!-- This section lists examples to indicate the roles of actors in -->
<!-- different use cases. -->
<!-- {{I-D.seitz-ace-usecases}} describes several use cases for constrained -->
<!-- environments. We use a selection of these use cases to show how they -->
<!-- can be mapped to our proposed architecture. -->
<!-- # Container Monitoring -->
<!-- In the container monitoring use case a supermarket chain buys bananas -->
<!-- from a Costa Rican fruit vendor and instructs a transport company to -->
<!-- deliver them. During transport, the bananas need to be cooled to keep -->
<!-- them from spoiling. -->
<!-- One example for a resource server in this use case is the device which -->
<!-- holds the temperature sensors and identification information for the -->
<!-- bananas. The temperature sensors are needed to ensure the cooling -->
<!-- during the journey, the identification information is used for -->
<!-- logistics, e.g. to find the right container. The sensors belong to the -->
<!-- supermarket chain, i.e. the supermarket decides who is allowed to -->
<!-- access. -->
<!-- One example for a client in this scenario is the cooling system of the -->
<!-- ship. It checks the temperature of the bananas regularly and adjusts -->
<!-- the temperature according to the measured values. The cooling system -->
<!-- belongs to the transport company which owns the ship, i.e. the -->
<!-- transport company decides about security policies for the device. -->
<!-- # Life Cycle -->
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>None</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>This document discusses security requirements for the ACE
architecture.</t>
<!-- TODO: need-to-know? owners must give only access rights to entities
that they must have -->
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>The author would like to thank Carsten Bormann, Olaf Bergmann, Robert
Cragie and Klaus Hartke for their valuable input and feedback.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC7228'>
<front>
<title>Terminology for Constrained-Node Networks</title>
<author initials='C.' surname='Bormann' fullname='C. Bormann'>
<organization /></author>
<author initials='M.' surname='Ersue' fullname='M. Ersue'>
<organization /></author>
<author initials='A.' surname='Keranen' fullname='A. Keranen'>
<organization /></author>
<date year='2014' month='May' />
<abstract>
<t>The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.</t></abstract></front>
<seriesInfo name='RFC' value='7228' />
<format type='TXT' octets='37635' target='http://www.rfc-editor.org/rfc/rfc7228.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding'>
<organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke'>
<organization /></author>
<date year='2014' month='June' />
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract></front>
<seriesInfo name='RFC' value='7230' />
<format type='TXT' octets='205947' target='http://www.rfc-editor.org/rfc/rfc7230.txt' />
</reference>
<reference anchor='RFC6347'>
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<author initials='N.' surname='Modadugu' fullname='N. Modadugu'>
<organization /></author>
<date year='2012' month='January' />
<abstract>
<t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6347' />
<format type='TXT' octets='73546' target='http://www.rfc-editor.org/rfc/rfc6347.txt' />
</reference>
<reference anchor='RFC7252'>
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'>
<organization /></author>
<author initials='K.' surname='Hartke' fullname='K. Hartke'>
<organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'>
<organization /></author>
<date year='2014' month='June' />
<abstract>
<t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t><t> CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t></abstract></front>
<seriesInfo name='RFC' value='7252' />
<format type='TXT' octets='258789' target='http://www.rfc-editor.org/rfc/rfc7252.txt' />
</reference>
<reference anchor='RFC5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'>
<organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2008' month='August' />
<abstract>
<t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5246' />
<format type='TXT' octets='222395' target='http://www.rfc-editor.org/rfc/rfc5246.txt' />
</reference>
<reference anchor='RFC4120'>
<front>
<title>The Kerberos Network Authentication Service (V5)</title>
<author initials='C.' surname='Neuman' fullname='C. Neuman'>
<organization /></author>
<author initials='T.' surname='Yu' fullname='T. Yu'>
<organization /></author>
<author initials='S.' surname='Hartman' fullname='S. Hartman'>
<organization /></author>
<author initials='K.' surname='Raeburn' fullname='K. Raeburn'>
<organization /></author>
<date year='2005' month='July' />
<abstract>
<t>This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4120' />
<format type='TXT' octets='340314' target='http://www.rfc-editor.org/rfc/rfc4120.txt' />
</reference>
<reference anchor='RFC6749'>
<front>
<title>The OAuth 2.0 Authorization Framework</title>
<author initials='D.' surname='Hardt' fullname='D. Hardt'>
<organization /></author>
<date year='2012' month='October' />
<abstract>
<t>The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6749' />
<format type='TXT' octets='163498' target='http://www.rfc-editor.org/rfc/rfc6749.txt' />
</reference>
<reference anchor='RFC4949'>
<front>
<title>Internet Security Glossary, Version 2</title>
<author initials='R.' surname='Shirey' fullname='R. Shirey'>
<organization /></author>
<date year='2007' month='August' />
<abstract>
<t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='4949' />
<format type='TXT' octets='867626' target='http://www.rfc-editor.org/rfc/rfc4949.txt' />
</reference>
<reference anchor='I-D.ietf-ace-usecases'>
<front>
<title>ACE use cases</title>
<author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
<organization />
</author>
<author initials='S' surname='Gerdes' fullname='Stefanie Gerdes'>
<organization />
</author>
<author initials='G' surname='Selander' fullname='Goran Selander'>
<organization />
</author>
<author initials='M' surname='Mani' fullname='Mehdi Mani'>
<organization />
</author>
<author initials='S' surname='Kumar' fullname='Sandeep Kumar'>
<organization />
</author>
<date month='February' day='5' year='2015' />
<abstract><t>Constrained devices are nodes with limited processing power, storage space and transmission capacities. These devices in many cases do not provide user interfaces and are often intended to interact without human intervention. This document comprises a collection of representative use cases for the application of authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the lifecylce of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and access control solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as communication protocol, however most conclusions apply generally.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-ace-usecases-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-ace-usecases-02.txt' />
</reference>
</references>
<section anchor="tasks" title="List of Tasks">
<t>This section defines the tasks which must be performed in the given
scenario (see <xref target="ps"/>) starting from communication related tasks and
then deriving the required security-related tasks. An overview of the
tasks can be found in <xref target="task_overview"/>.</t>
<t>A task has the following structure:</t>
<t><list style="symbols">
<t>The name of the task which has the form TXXX</t>
<t>One or more Requirements (if applicable) of the form RqXXX</t>
<t>One or more Preconditions (if applicable) of the form PreXXX</t>
<t>One or more Postconditions (if applicable) of the form PostXXX</t>
</list></t>
<t>Requirements have to be met <spanx style="emph">while</spanx> performing the task. They derive
directly from the scenario (see <xref target="ps"/>) or from the security
requirements defined for the scenario. Preconditions have to be
fulfilled <spanx style="emph">before</spanx> conducting the task. Postconditions are the
<spanx style="emph">results</spanx> of the completed task.</t>
<t>We start our analysis with the processing tasks and define which preconditions
need to be fulfilled before these tasks can be conducted. We then
determine which tasks therefore need to be performed first (have
postconditions which match the respective preconditions).</t>
<t>Note: Regarding the communication, C and S are defined as entities
each having their set of attributes and a verifier which is bound to
these attributes. Attributes are not necessarily usable to identify an
individual C or S. Several entities might have the same attributes.</t>
<section anchor="basic-scenario" title="Basic Scenario">
<t>The intended result of the interaction between C and S is that C has
successfully accessed R. C gets to know that its access
request was successful by receiving the answer from S.</t>
<t>The transmission of information from C to S comprises two parts:
sending the information on one side and receiving and processing it on
the other. Security has to be considered at each of these steps.</t>
<section anchor="proc_info" title="Processing Information">
<!-- TODO: remove proxy stuff -->
<t>The purpose of the communication between C and S is C’s intent to
access R. To achieve this, S must process the information about the
requested access and C
must process the information in the response to a requested access. The
request and the response might both contain resource values.</t>
<t>The confidentiality and integrity of R require that only
authorized entities are able to access R (see Rq0.1). Therefore, C and
S must check that the information is authentic and that the source of
the information is authorized to provide it, before the information
can be processed. C must validate that S is an authorized source for
R. S must validate that C is authorized to access R as requested.</t>
<t>If proxies are used, it depends on the type of proxy how they are
integrated into the communication and what kind of security
relationships need to be established.
A future version of this document will provide more
details on this topic. At this point we assume that C and S might
receive the information either from S or C directly or from a proxy
which is authorized to speak for the respective communication partner.</t>
<t><list style="symbols">
<t>Task TProcResp: Process the response to an access request.<vspace />
Description: C processes the response to an access request
according to the reason for requesting the resource in the first
place. The response might include resource values or information
about the results of a request.<vspace />
Requirements:<vspace />
* RqProcResp.1: Is performed by C (derives from the problem
statement).<vspace />
* RqProcResp.2: Must be performable by a constrained device
(derives from the problem statement: C and / or S are
constrained).<vspace />
Preconditions:<vspace />
* PreProcResp.1: A response to an access request was sent (see
<xref target="send_info"/>).<vspace />
* PreProcResp.2 (required for Rq0.2): C validated that the
response to an access request is authentic, i.e. it stems
from the entity requested in TSendReq (see <xref target="send_info"/>),
i.e. S or an entity which is authorized to speak for S
(see <xref target="inf_authn"/>).<vspace />
* PreProcResp.3 (required for Rq0.2): C validated that S or the
entity which is authorized to speak for S is an authorized
source for R (see <xref target="authz_val"/>).<vspace />
Postcondition:<vspace />
* PostProcResp.1: C processed the response. </t>
<t>Task TProcReq: Process an access request.<vspace />
Description: S either performs an action on the resource according
to the information in the request, or determines the reason for not
performing an action.<vspace />
Requirements:<vspace />
* RqProcReq.1: Is performed by S.<vspace />
* RqProcReq.2: Must be performable by a constrained device
(derives from the problem statement: C and / or S are
constrained).<vspace />
Preconditions:<vspace />
* PreProcReq.1: An access request was sent (see <xref target="send_info"/>).<vspace />
* PreProcReq.2 (needed for Rq0.1): S validated that the
request is authentic, i.e. it stems from C or an entity
which is authorized to speak for C and is fresh. (see
<xref target="inf_authn"/>).<vspace />
* PreProcReq.3 (needed for Rq0.1): S validated the
authorization of C or the entity which is authorized to
speak for C to access the resource as requested
(see <xref target="authz_val"/>).<vspace />
Postconditions:<vspace />
* PostProcReq.1: The access request was processed (fulfills
PreSendResp.1, see <xref target="send_info"/>).</t>
</list></t>
<t>Note: The preconditions PreProcReq.2 and PreProcReq.3 must be
conducted together. S must assure that the response is bound to a
verifier, the verifier is bound to certain attributes and
the authorization information refers to these attributes.</t>
</section>
<section anchor="send_info" title="Sending Information">
<t>The information needed for processing has to be transmitted at some
point. C has to transmit to S which resource it wants to access with
which actions and parameters. S has to transmit to C the result of
the request. The request and the response might both contain resource
values. To fulfill Rq0.1, the confidentiality and integrity of the
transmitted data has to be assured.</t>
<t>If proxies are used, it depends on the type of proxy how they need to
be handled. A future version of this document will provide more
details on this topic. At this point we assume that C and S might
transmit the message either to S and C directly or to a proxy which
is authorized to speak for the respective communication partner.</t>
<t><list style="symbols">
<t>Task TSendReq: Securely transmit an access request.<vspace />
Description: C wants to access a resource R hosted by the resource
server S. To achieve this, it has to transmit some information to
S such as the resource to be accessed, the action to be performed
on the resource and, if a writing access is requested, the value to
write. C might send the request directly to S or to an entity
which is authorized to speak for S. C assures that the request
reaches the proper R. C binds the request to C’s verifier to ensure
the integrity of the message. C uses means to assure that no
unauthorized entity is able to access the information in the
request.<vspace />
Requirements:<vspace />
* RqSendReq.1: Is performed by C (derives from problem statement).<vspace />
* RqSendReq.2: Must be performable by a constrained device
(derives
from the problem statement: C and / or S are constrained).<vspace />
* RqSendReq.3: As the request might contain resource values,
the confidentiality and integrity of the request must be
ensured during transmission. Only authorized parties must be
able to read or modify the request (derives from Rq0.1).<vspace />
Preconditions:<vspace />
* PreSendReq.1: Validate that the receiver is an authorized
source for R (see <xref target="authz_val"/>).<vspace />
* PreSendReq.2: To assure that the request reaches the proper
S, that no unauthorized party is able to access the request, and
that the information in the request is bound to C’s verifier
it is necessary to negotiate means for secure communication
with S (see <xref target="secure_comm"/>).<vspace />
Postconditions:<vspace />
* PostSendReq.1: The request was sent securely to S
(necessary for Rq0.1) (fulfills PreProcReq.1, see
<xref target="proc_info"/>). </t>
</list></t>
<t>Note: The preconditions PreSendReq.1 and PreSendReq.2 must be
conducted together. C must assure that the request reaches an entity
with certain attributes and that the authorization information refers
to these attributes.</t>
<t><list style="symbols">
<t>Task TSendResp: Securely transmit a response to an access request.<vspace />
Description: S sends a response to an access request to inform C
about the result of the request. S must assure that response
reaches the requesting C. S might send the response to C or to an
entity which is authorized to speak for C. The response might
contain resource values. S binds the request to S’s verifier to ensure
the integrity of the message. S uses means to assure that no
unauthorized entity is able to access the information in the
response.<vspace />
Requirements:<vspace />
* RqSendResp.1: Is performed by S (derives from the
problem statement).<vspace />
* RqSendResp.2: Must be performable by a constrained
device (derives from the problem statement: C and / or S
are constrained).<vspace />
* RqSendResp.3: As the response might contain resource
values, the confidentiality and integrity of the response
must be ensured during transmission. Only authorized parties
must be able to read or modify the response (derives from
Rq0.1).<vspace />
Preconditions:<vspace />
* PreSendResp.1: An access request was processed (see
<xref target="proc_info"/>).<vspace />
* PreSendResp.2: If information about R is transmitted,
validate that the receiver is authorized
to access R (see <xref target="authz_val"/>).<vspace />
* PreSendResp.3: S must assure that the response reaches the
requesting C, no unauthorized party is able to access the
response and the information in the response is bound to S’
verifier: Means for secure communication were
negotiated (see <xref target="secure_comm"/>).<vspace />
Postconditions:<vspace />
* PostSendResp.1: A response to an access request was sent
(fulfills PreProcResp.1, see <xref target="proc_info"/>).</t>
</list></t>
<!-- TODO: ist nicht alles immer erforderlich, kommt auf die
sicherheitsziele an -->
</section>
</section>
<section anchor="security-related-tasks-1" title="Security-Related Tasks">
<section anchor="inf_authn" title="Information Authenticity">
<t>This section addresses information authentication, i.e. using the
verifier to validate the source of an information. Information
authentication must be conducted before processing received
information. C must validate that a response to
an access request is fresh, really stems from the queried S (or an
entity which is authorized to speak for S) and was not modified during
transmission. S must validate that the information in the access
request is fresh, really stems from C (or an entity which is authorized
to speak for C) and was not modified during transmission.</t>
<!-- TODO: explain freshness requirement -->
<t>The entity which processes the information must be the entity which is
validating the source of the information.</t>
<t>C and S must assure that the authenticated source of the information
is authorized to provide the information.</t>
<!-- TODO: mention endorsement validation -->
<t><list style="symbols">
<t>Task TAuthnResp: Validate that the response to an access request
is authentic.<vspace />
Description: C checks if the response to an access request stems
from an entity in possession of the respective verifier and is
fresh. Thus, C validates that the response stems from the queried S or an
entity which is authorized to speak for S.<vspace />
Requirements:<vspace />
* RqAuthnResp.1: Must be performed by C.<vspace />
* RqAuthnResp.2: Must be performable by a constrained
device (derives from the problem statement: C and / or S
are constrained).<vspace />
Preconditions:<vspace />
* PreAuthnResp.1: Means for secure communication were
negotiated (see <xref target="secure_comm"/>).<vspace />
Postconditions:<vspace />
* PostAuthnResp.1: C knows that the response came from S
(fulfills PreProcResp.2, see <xref target="proc_info"/>).</t>
<t>Task TAuthnReq: Validate the authenticity of a request.<vspace />
Description: S checks if the request stems from an entity in
possession of the respective verifier and is fresh. Thus, S
validates that the request stems from C or an entity which is
authorized to speak
for C.<vspace />
Requirements:<vspace />
* RqAuthnReq.1: Must be performed by S.<vspace />
* RqAuthnReq.2: Must be performable by a constrained device
(derives from the problem statement: C and / or S are
constrained).<vspace />
Preconditions:<vspace />
* PreAuthnReq.1: Means for secure communication were
negotiated (see <xref target="secure_comm"/>).<vspace />
Postconditions:<vspace />
* PostAuthnReq.1: S knows that the request is authentic
(fulfills PreProcReq.2, see <xref target="proc_info"/>).</t>
</list></t>
</section>
<section anchor="authz_val" title="Authorization Validation">
<!-- We differentiate the configuration of authorization information,
the obtaining of the authorization information and the validation of
the authorization. -->
<t>This section addresses the validation of the authorization of an
entity. The entity which processes the information must validate that
the source of the information is authorized to provide it. The
processing entity has to verify that the source of the information has
certain attributes which authorize it to provide the information: C
must validate that S (or the entity which speaks for S) is in
possession of attributes which are necessary for being an authorized
source for R. S must validate that C (or the entity which speaks for
C) has attributes which are necessary for a permission to access R as
requested.</t>
<!-- TODO: mention authorization enforcement -->
<t><list style="symbols">
<t>Task TValSourceAuthz: Validate that an entity is an authorized source for
R.<vspace />
Description: C checks if according to COP’s
authorization policy and the authentication endorsement provided by
the attribute binding authority, S (or an entity which speaks for
S) is authorized to be a source for R. S assures that
the entity’s verifier is bound to certain attributes and the
authorization information refers to these attributes.<vspace />
Requirements:<vspace />
* RqValSourceAuthz.1: Is performed by C<vspace />
* RqValSourceAuthz.2: Must be performable by a constrained device
(derives from the problem statement: C and / or S are
constrained).<vspace />
Preconditions:<vspace />
* PreValSourceAuthz.1: Authorization information about the entity
is available. Requires obtaining authorization information
about the entity from C’s principal (see <xref target="obtain_authz"/>).<vspace />
* PreValSourceAuthz.2: Means to validate that the entity has
certain attributes which are relevant for the authorization:
Requires validation of claims about S (see <xref target="claim_val"/>).<vspace />
Postconditions:<vspace />
* PostValSourceAuthz.1: The entity which performs the task
knows that an entity is an authorized source for R (fulfills
PreProcResp.3, see <xref target="proc_info"/> and PreSendReq.1, see
<xref target="send_info"/>). </t>
<t>Task TValAccessAuthZ: Validate the authorization of the requester
to access
the requested resource as requested.<vspace />
Description: R’s principal configures which clients are authorized to
perform which action on R. S has to check if according to ROP’s
authorization policy and the authentication endorsement provided by
the attribute binding authority, C (or an entity which speaks for
C) is authorized to access R as requested. S assures that
requester’s verifier is bound to certain attributes and the
authorization information refers to these attributes.<vspace />
Requirements:<vspace />
* RqValAccessAuthz.1: Is performed by S<vspace />
* RqValAccessAuthz.2: Must be performable by a constrained
device (derives from the problem statement: C and / or S
are
constrained).<vspace />
Preconditions:<vspace />
* PreValAccessAuthz.1: Authorization information about the entity
are available. Requires obtaining authorization information
about the entity from S’s principal (see <xref target="obtain_authz"/>).<vspace />
* PreValAccessAuthz.2: Means to validate that the entity has
certain attributes which are relevant for the authorization:
Requires validation of claims about C or the entity which
speaks for C (see <xref target="claim_val"/>).<vspace />
Postconditions:<vspace />
* PostValAccessAuthz.1: The entity which performs the task knows
that an entity is authorized to access R with the requested
action (fulfills PreProcReq.3, see <xref target="proc_info"/>).</t>
</list></t>
</section>
<section anchor="secure_comm" title="Transmission Security">
<t>To ensure the confidentiality and integrity of information during
transmission means for secure communication have to be negotiated
between the communicating parties.</t>
<t><list style="symbols">
<t>Task TSecureComm: Negotiate means for secure communication.<vspace />
Description: To ensure the confidentiality and integrity of
transmitted information, means for secure communication have to be
negotiated. Channel security as well as object security solutions
are possible. Details depend on the used solution and are not in
the scope of this document.<vspace />
Requirements:<vspace />
* RqSecureComm.1: Must be performable by a constrained device
(derives from the problem statement: C and / or S are
constrained).<vspace />
Preconditions:<vspace />
* PreSecureComm.1: Sender and receiver must be able to
validate that the entity in possession of a certain
verifier has the claimed attributes. (see <xref target="claim_val"/>).<vspace />
Postconditions:<vspace />
* PostSecureComm.1: C and S can communicate securely: The
integrity and confidentiality of information is ensured
during transmission. The sending entity can use means to
assure that the information reaches the intended receiver
so that no unauthorized party is able to access the
information. The sending entity can bind the information to
the entity’s verifier (fulfills PreSendResp.3 and
PreSendReq.2, see <xref target="send_info"/> as well as
PreAuthnResp.1 and PreAuthnReq.1, see <xref target="inf_authn"/>).</t>
</list></t>
</section>
<section anchor="obtain_authz" title="Obtain Authorization information">
<t>As described in <xref target="authz_tasks"/>, the authorization of an entity
requires several steps. The authorization information must be
configured by the principal and provided to the enforcing entity.</t>
<t><list style="symbols">
<t>Task TObtainSourceAuthz: Obtain authorization information about an entity
from C’s principal.<vspace />
Description: C’s principal defines authorized sources for R. The
authorization information must be made available to C to enable it
to enforce COP’s authorization information. To facilitate the
configuration for the principal this device should have a user
interface. The authorization information has to be made available
to C in a secure way.<vspace />
Requirements:<vspace />
* RqObtainSourceAuthz.1: Must be performed by an entity which
is authorized by C’s principal.<vspace />
* RqObtainSourceAuthz.2: Must be performed by an entity which
is authorized to speak for C’s principal concerning authorized
sources for R.<vspace />
* RqObtainSourceAuthz.3: Should be performed by a device which
can provide some sort of user interface to facilitate the
configuration of authorization information for C’s principal.<vspace />
Preconditions:<vspace />
* PreObtainSourceAuthz.1: C’s principal configured authorized
sources for R (see <xref target="config_authz"/>).<vspace />
Postconditions:<vspace />
* PostObtainSourceAuthz.1: C obtained S’ authorization to be
a source for R (fulfills PreValSourceAuthz.1, see
<xref target="authz_val"/>).</t>
<t>Task TObtainAccessAuthz: Obtain authorization information about an entity
from S’ principal.<vspace />
Description: S’ principal defines if and how C is
authorized to access R. The authorization information must be made
available to S to enable it to enforce ROP’s authorization
policies. To facilitate the configuration for the principal this device
should have a user interface. The authorization information has to
be made available to S in a secure way.<vspace />
Requirements:<vspace />
* RqObtainAccessAuthz.1: Must be performed by an entity which
is authorized by R’s principal.<vspace />
* RqObtainAccessAuthz.2: Must be performed by an entity which
is authorized to speak for R’s principal concerning
authorization of access to R.<vspace />
* RqObtainAccessAuthz.3: Should be performed by a device which
can provide some sort of user interface to facilitate the
configuration of authorization information for R’s principal.<vspace />
Preconditions:<vspace />
* PreObtainAccessAuthz.1: R’s principal configured authorization
information for the access to R (see <xref target="config_authz"/>).<vspace />
Postconditions:<vspace />
* PostObtainAccessAuthz.1: S obtained C’s authorization for
accessing R (fulfills PreValAccessAuthz.1, see
<xref target="authz_val"/>).</t>
</list></t>
</section>
<section anchor="claim_val" title="Attribute Binding">
<t>As described in <xref target="authn_tasks"/>, several steps must be conducted for
authentication. This section addresses the binding of attributes to a
verifier.</t>
<t>For authentication it is necessary to validate if an
entity has certain attributes. An example for such an attribute
in the physical world is the name of a person or her age. In
constrained environments, attributes might be the name of the owner or
the type of device. Authorizations are bound to such attributes.</t>
<t>The possession of attributes must be verifiable. For that purpose,
attributes must be bound to a verifier. An example for a verifier in
the physical world is a passport. In constrained environments, a
verifier will likely be the knowledge of a secret.</t>
<t>At some point, an authority has to check if an entity in possession of
the verifier really possesses the claimed attributes. In the physical
world, government agencies check your name and age before they give
you a passport.</t>
<t>The entity that validates the claims has to provide some kind of seal
to make its endorsement verifiable for other entities and thus bind
the attributes to the verifier. In the physical world passports are
stamped by the issuing government agencies (and must only be provided by
government agencies anyway).</t>
<t><list style="symbols">
<t>Task TValSourceAttr: Validate on the client side that an entity has
certain attributes.<vspace />
Description: The claim that an entity has certain attributes has to
be checked and made available for C in a secure way. The validating
party states that an entity in possession of a certain key has
certain attributes and provides C with means to validate this
endorsement.<vspace />
Requirements:<vspace />
* RqValSourceAttr.1: Must be performed by an entity which
is authorized by C’s principal to validate claims about S.<vspace />
* RqValSourceAttr.3: The executing entity must have the means
to fulfill the task (e.g. enough storage space,
computational power, a user interface to facilitate the
configuration of authentication policies).<vspace />
Postconditions:<vspace />
* PostValSourceAttr.1: Means for authenticating (validating
the attribute-verifier-binding of) other entities were given
to C in form of a verifiable endorsement (fulfills
PreValSourceAuthz.2, see <xref target="authz_val"/> and PreSecureComm.1,
see <xref target="secure_comm"/>).</t>
<t>Task TValReqAttr: Validate on the server side that an entity has
certain attributes.<vspace />
Description: The claim that an entity has certain attributes has to
be checked and made available for S in a secure way. The
validating party states that an entity in possession of a certain
key has certain attributes and provides S with means to validate
this endorsement.<vspace />
Requirements:<vspace />
* RqValReqAttr.1: Must be performed by an entity which is
authorized by S’ principal to validate claims about C.<vspace />
* RqValReqAttr.2: The executing entity must have the means to fulfill
the task (e.g. enough storage space, computational power, a
user interface to facilitate the configuration of
authentication policies).<vspace />
Postconditions:<vspace />
* PostValReqAttr.1: Means for authenticating (validating the
attribute-verifier-binding of) other entities were given to
S in form of a verifiable endorsement (fulfills
PreValSourceAuthz.2, see <xref target="authz_val"/> and PreSecureComm.1,
see <xref target="secure_comm"/>).</t>
</list></t>
</section>
<section anchor="config_authz" title="Configuration of Authorization Information">
<t>As stated in <xref target="authz_tasks"/>, several steps have to be conducted for
authorization. This section is about the configuration of
authorization information.</t>
<t>The principal of a device or resource wants to be in control of her device
and her data. For that purpose, she has to configure authorization
information. C’s principal might want to configure which attributes an entity
must have to be allowed to represent R. R’s principal might want to configure
which attributes are required for accessing R with a certain action.</t>
<t><list style="symbols">
<t>Task TConfigSourceAuthz: Configure for C authorization information for
sources for R.<vspace />
Description: C’s principal has to define authorized sources for R.<vspace />
Requirements:<vspace />
* RqConfigSourceAuthz.1: Must be provided by C’s principal.<vspace />
Postconditions:<vspace />
* PostConfigSourceAuthz.1: The authorization information are
available to a device which performs TObtainSourceAuthz
(fulfills PreObtainSourceAuthz.1 see <xref target="obtain_authz"/>).</t>
<t>Task TConfigAccessAuthz: Configure for S authorization information for
accessing R.<vspace />
Description: R’s principal has to configure if and how an entity with
certain attributes is allowed to access R.<vspace />
Requirements:<vspace />
* RqConfigAccessAuthz.1: Must be provided by R’s principal.<vspace />
Postconditions:<vspace />
* PostConfigAccessAuthz.1: The authorization information are
available to the device which performs TObtainAccessAuthz
(fulfills PreObtainAccessAuthz.1, see <xref target="obtain_authz"/>).</t>
</list></t>
</section>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 20:53:03 |