Internet DRAFT - draft-gerdes-ace-tasks
draft-gerdes-ace-tasks
ACE Working Group S. Gerdes
Internet-Draft Universitaet Bremen TZI
Intended status: Informational September 29, 2015
Expires: April 1, 2016
Authorization-Related Tasks in Constrained Environments
draft-gerdes-ace-tasks-00
Abstract
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.
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
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 April 1, 2016.
Gerdes Expires April 1, 2016 [Page 1]
Internet-Draft ace-tasks September 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Basic Scenario Tasks . . . . . . . . . . . . . . . . . . 4
3.2. Security-Related Tasks . . . . . . . . . . . . . . . . . 4
3.3. Authentication-Related Tasks . . . . . . . . . . . . . . 5
3.4. Authorization-Related Tasks . . . . . . . . . . . . . . . 5
4. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Constrained Level Actors . . . . . . . . . . . . . . . . 7
4.2. Principal Level Actors . . . . . . . . . . . . . . . . . 8
4.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. Informative References . . . . . . . . . . . . . . . . . . . 11
Appendix A. List of Tasks . . . . . . . . . . . . . . . . . . . 11
A.1. Basic Scenario . . . . . . . . . . . . . . . . . . . . . 12
A.1.1. Processing Information . . . . . . . . . . . . . . . 12
A.1.2. Sending Information . . . . . . . . . . . . . . . . . 13
A.2. Security-Related Tasks . . . . . . . . . . . . . . . . . 15
A.2.1. Information Authenticity . . . . . . . . . . . . . . 15
A.2.2. Authorization Validation . . . . . . . . . . . . . . 16
A.2.3. Transmission Security . . . . . . . . . . . . . . . . 17
A.2.4. Obtain Authorization information . . . . . . . . . . 17
A.2.5. Attribute Binding . . . . . . . . . . . . . . . . . . 18
A.2.6. Configuration of Authorization Information . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
Gerdes Expires April 1, 2016 [Page 2]
Internet-Draft ace-tasks September 2015
1. Introduction
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.
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.
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.
In this document, the required authorization-related tasks are
identified as guidance for the development of authentication and
authorization solutions for constrained environments.
1.1. Terminology
Readers are required to be familiar with the terms and concepts
defined in [RFC4949] and [I-D.ietf-ace-actors].
2. Problem Statement
The scenario this document addresses can be summarized as follows:
o C wants to access R on a S.
o A priori, C and S do not necessarily know each other and have no
security relationship.
o C and / or S are constrained.
Gerdes Expires April 1, 2016 [Page 3]
Internet-Draft ace-tasks September 2015
------- -------
| C | -- requests resource ---> | S |
------- <-- provides resource--- -------
Figure 1: Basic Scenario
The security requirements of any specific version of this scenario
will include one or more of:
o Rq0.1: No unauthorized entity has access to (or otherwise gains
knowledge of) R.
o 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).
Rq0.1 requires authorization on the server side while Rq0.2 requires
authorization on the client side.
3. Tasks
This section gives an overview of the tasks which must be performed
in the given scenario (see Section 2) to meet any specific security
requirements.
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.
3.1. Basic Scenario Tasks
This document does not assume a specific transfer protocol. We
assume however, that at least the following information is exchanged
between the client and the server:
o 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.
o S transmits to C the result of the attempted access.
3.2. Security-Related Tasks
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
Gerdes Expires April 1, 2016 [Page 4]
Internet-Draft ace-tasks September 2015
that the entity that sent the information used for processing is
authorized to provide it.
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.
3.3. Authentication-Related Tasks
Several steps must be conducted for authenticating certain attributes
of an entity and validating the authenticity of an information:
1. 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.
Note: The attribute binding can be conducted using either symmetric
or asymmetric cryptography.
1. 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.
2. 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.
Step 1 is addressed in Appendix A.2.5. 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. Tasks
for step 2 and 3 are Information authenticity (see Appendix A.2.1)
and secure communication (see Appendix A.2.3).
3.4. Authorization-Related Tasks
Several steps must be conducted for explicit authorization:
1. Configuration of authorization information: The respective
principals (COP and ROP) must configure the authorization
Gerdes Expires April 1, 2016 [Page 5]
Internet-Draft ace-tasks September 2015
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.
2. Obtaining authorization information: Authorization information
must be made available to the entity which enforces the
authorization.
3. 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.
4. Authorization enforcement: According to the result of the
authorization validation the access to a resource is granted or
denied.
Tasks for step 1 are defined in Appendix A.2.6. Appendix A.2.4
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. Appendix A.2.2
introduces tasks for these steps.
4. Actors
This section describes how the tasks defined in Appendix A are mapped
to the various actors in the architecture (see also
[I-D.ietf-ace-actors]). 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.
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.
The concept of actors is used to assign the tasks defined in
Appendix A to logical functional entities.
Gerdes Expires April 1, 2016 [Page 6]
Internet-Draft ace-tasks September 2015
4.1. Constrained Level Actors
As described in the problem statement (see Section 2), 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.
C performs the following tasks:
o Negotiate means for secure communication (Task TSecureComm, see
Appendix A.2.3).
o Validate that an entity is an authorized source for R (Task
TValSourceAuthz, see Appendix A.2.2).
o Securely transmit an access request (Task TSendReq, see
Appendix A.1.2).
o Validate that the response to an access request is authentic (Task
TAuthnResp, see Appendix A.2.1).
o Process the response to an access request (Task TProcResp, see
Appendix A.1.1).
S performs the following tasks:
o Negotiate means for secure communication (Task TSecureComm, see
Appendix A.2.3).
o Validate the authenticity of an access request (Task TAuthnReq,
see Appendix A.2.1).
o Validate the authorization of the requester to access the
requested resource as requested (Task TValAccessAuthZ, see
Appendix A.2.2).
o Process an access request (Task TProcReq, see Appendix A.1.1).
o Securely transmit a response to an access request (Task TSendResp,
see Appendix A.1.2).
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 ROPs.
For simplicity of exposition, these resources are described as if
they had separate S.
Gerdes Expires April 1, 2016 [Page 7]
Internet-Draft ace-tasks September 2015
As C and S do not necessarily know each other they might belong to
different security domains.
------- -------
| C | -- requests resource ---> | S | Constrained Level
------- <-- provides resource--- -------
Figure 2: Constrained Level Actors
4.2. Principal Level Actors
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 endpoints and
belong to the same security domain.
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.
COP must fulfill the following task:
o Configure for C authorization information for sources for R (Task
TConfigSourceAuthz, see Appendix A.2.6).
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.
ROP must fulfill the following task:
o Configure for S authorization information for accessing R (Task
TConfigAccessAuthz, see Appendix A.2.6).
Gerdes Expires April 1, 2016 [Page 8]
Internet-Draft ace-tasks September 2015
------- -------
| COP | | ROP | Principal Level
------- -------
| |
in charge of in charge of
| |
V V
------- -------
| C | -- requests resource ---> | S | Constrained Level
------- <-- provides resource--- -------
Figure 3: Constrained Level Actors and Principal Level Actors
4.3. Less-Constrained Level Actors
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 endpoints 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.
The Client Authorization Server (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.
CAM performs the following tasks:
o Validate on the client side that an entity has certain attributes
(Task TValSourceAttr, see Appendix A.2.5).
o Obtain authorization information about an entity from C's
principal (COP) and provide it to C. (Task TObtainSourceAuthz,
see Appendix A.2.4).
o Negotiate means for secure communication to communicate with C
(Task TSecureComm, see Appendix A.2.3).
The Authorization Server (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.
SAM performs the following tasks:
Gerdes Expires April 1, 2016 [Page 9]
Internet-Draft ace-tasks September 2015
o Validate on the server side that an entity has certain attributes
(Task TValReqAttr, see Appendix A.2.5).
o Obtain authorization information about an entity from S' principal
(ROP) and provide it to S (Task TObtainAccessAuthz, see
Appendix A.2.4).
o Negotiate means for secure communication to communicate with S
(Task TSecureComm, see Appendix A.2.3).
------- -------
| 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 -- -------
Figure 4: Overview of all Complexity Levels
For more detailed graphics please consult the PDF version.
5. IANA Considerations
None
6. Security Considerations
This document discusses authorization-related tasks for constrained
environments and describes how these tasks can be mapped to actors in
the architecture.
Gerdes Expires April 1, 2016 [Page 10]
Internet-Draft ace-tasks September 2015
7. Acknowledgments
The author would like to thank Carsten Bormann, Olaf Bergmann, Robert
Cragie and Klaus Hartke for their valuable input and feedback.
8. Informative References
[I-D.ietf-ace-actors]
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.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI
36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>.
Appendix A. List of Tasks
This section defines the tasks which must be performed in the given
scenario (see Section 2) starting from communication related tasks
and then deriving the required security-related tasks. An overview
of the tasks can be found in Section 3.
A task has the following structure:
o The name of the task which has the form TXXX
o One or more Requirements (if applicable) of the form RqXXX
o One or more Preconditions (if applicable) of the form PreXXX
o One or more Postconditions (if applicable) of the form PostXXX
Requirements have to be met _while_ performing the task. They derive
directly from the scenario (see Section 2) or from the security
requirements defined for the scenario. Preconditions have to be
fulfilled _before_ conducting the task. Postconditions are the
_results_ of the completed task.
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).
Note: Regarding the communication, C and S are defined as entities
each having their set of attributes and a verifier which is bound to
Gerdes Expires April 1, 2016 [Page 11]
Internet-Draft ace-tasks September 2015
these attributes. Attributes are not necessarily usable to identify
an individual C or S. Several entities might have the same
attributes.
A.1. Basic Scenario
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.
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.
A.1.1. Processing Information
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.
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.
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.
o Task TProcResp: Process the response to an access request.
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. Requirements: * RqProcResp.1: Is
performed by C (derives from the problem statement). *
RqProcResp.2: Must be performable by a constrained device (derives
from the problem statement: C and / or S are constrained).
Preconditions: * PreProcResp.1: A response to an access request
was sent (see Appendix A.1.2). * PreProcResp.2 (required for
Rq0.2): C validated that the response to an access request is
Gerdes Expires April 1, 2016 [Page 12]
Internet-Draft ace-tasks September 2015
authentic, i.e. it stems from the entity requested in TSendReq
(see Appendix A.1.2), i.e. S or an entity which is authorized to
speak for S (see Appendix A.2.1). * 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 Appendix A.2.2).
Postcondition: * PostProcResp.1: C processed the response.
o Task TProcReq: Process an access request. 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. Requirements: * RqProcReq.1: Is performed by S. *
RqProcReq.2: Must be performable by a constrained device (derives
from the problem statement: C and / or S are constrained).
Preconditions: * PreProcReq.1: An access request was sent (see
Appendix A.1.2). * 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
Appendix A.2.1). * 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 Appendix A.2.2).
Postconditions: * PostProcReq.1: The access request was processed
(fulfills PreSendResp.1, see Appendix A.1.2).
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.
A.1.2. Sending Information
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.
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.
o Task TSendReq: Securely transmit an access request. 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
Gerdes Expires April 1, 2016 [Page 13]
Internet-Draft ace-tasks September 2015
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. Requirements: * RqSendReq.1: Is performed by C (derives
from problem statement). * RqSendReq.2: Must be performable by a
constrained device (derives from the problem statement: C and / or
S are constrained). * 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).
Preconditions: * PreSendReq.1: Validate that the receiver is an
authorized source for R (see Appendix A.2.2). * 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 Appendix A.2.3).
Postconditions: * PostSendReq.1: The request was sent securely to
S (necessary for Rq0.1) (fulfills PreProcReq.1, see
Appendix A.1.1).
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.
o Task TSendResp: Securely transmit a response to an access request.
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. Requirements: * RqSendResp.1: Is performed by S
(derives from the problem statement). * RqSendResp.2: Must be
performable by a constrained device (derives from the problem
statement: C and / or S are constrained). * 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). Preconditions: * PreSendResp.1: An
access request was processed (see Appendix A.1.1). *
PreSendResp.2: If information about R is transmitted, validate
that the receiver is authorized to access R (see Appendix A.2.2).
* PreSendResp.3: S must assure that the response reaches the
requesting C, no unauthorized party is able to access the response
Gerdes Expires April 1, 2016 [Page 14]
Internet-Draft ace-tasks September 2015
and the information in the response is bound to S' verifier: Means
for secure communication were negotiated (see Appendix A.2.3).
Postconditions: * PostSendResp.1: A response to an access request
was sent (fulfills PreProcResp.1, see Appendix A.1.1).
A.2. Security-Related Tasks
A.2.1. Information Authenticity
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.
The entity which processes the information must be the entity which
is validating the source of the information.
C and S must assure that the authenticated source of the information
is authorized to provide the information.
o Task TAuthnResp: Validate that the response to an access request
is authentic. 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. Requirements: * RqAuthnResp.1: Must be performed by C. *
RqAuthnResp.2: Must be performable by a constrained device
(derives from the problem statement: C and / or S are
constrained). Preconditions: * PreAuthnResp.1: Means for secure
communication were negotiated (see Appendix A.2.3).
Postconditions: * PostAuthnResp.1: C knows that the response came
from S (fulfills PreProcResp.2, see Appendix A.1.1).
o Task TAuthnReq: Validate the authenticity of a request.
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. Requirements: * RqAuthnReq.1: Must be
performed by S. * RqAuthnReq.2: Must be performable by a
constrained device (derives from the problem statement: C and / or
S are constrained). Preconditions: * PreAuthnReq.1: Means for
secure communication were negotiated (see Appendix A.2.3).
Gerdes Expires April 1, 2016 [Page 15]
Internet-Draft ace-tasks September 2015
Postconditions: * PostAuthnReq.1: S knows that the request is
authentic (fulfills PreProcReq.2, see Appendix A.1.1).
A.2.2. Authorization Validation
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.
o Task TValSourceAuthz: Validate that an entity is an authorized
source for R. 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.
Requirements: * RqValSourceAuthz.1: Is performed by C *
RqValSourceAuthz.2: Must be performable by a constrained device
(derives from the problem statement: C and / or S are
constrained). Preconditions: * PreValSourceAuthz.1: Authorization
information about the entity is available. Requires obtaining
authorization information about the entity from COP (see
Appendix A.2.4). * PreValSourceAuthz.2: Means to validate that
the entity has certain attributes which are relevant for the
authorization: Requires validation of claims about S (see
Appendix A.2.5). Postconditions: * PostValSourceAuthz.1: The
entity which performs the task knows that an entity is an
authorized source for R (fulfills PreProcResp.3, see
Appendix A.1.1 and PreSendReq.1, see Appendix A.1.2).
o Task TValAccessAuthZ: Validate the authorization of the requester
to access the requested resource as requested. Description: ROP
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. Requirements: * RqValAccessAuthz.1:
Is performed by S * RqValAccessAuthz.2: Must be performable by a
constrained device (derives from the problem statement: C and / or
Gerdes Expires April 1, 2016 [Page 16]
Internet-Draft ace-tasks September 2015
S are constrained). Preconditions: * PreValAccessAuthz.1:
Authorization information about the entity are available.
Requires obtaining authorization information about the entity from
ROP (see Appendix A.2.4). * 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 Appendix A.2.5).
Postconditions: * 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 Appendix A.1.1).
A.2.3. Transmission Security
To ensure the confidentiality and integrity of information during
transmission means for secure communication have to be negotiated
between the communicating parties.
o Task TSecureComm: Negotiate means for secure communication.
Description: To ensure the confidentiality and integrity of
transmitted information, means for secure communication (e.g.
session keys, used cipher suites, etc.) 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. Requirements: * RqSecureComm.1: Must be
performable by a constrained device (derives from the problem
statement: C and / or S are constrained). Preconditions: *
PreSecureComm.1: Sender and receiver must be able to validate that
the entity in possession of a certain verifier has the claimed
attributes. (see Appendix A.2.5). Postconditions: *
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 Appendix A.1.2 as well as PreAuthnResp.1 and
PreAuthnReq.1, see Appendix A.2.1).
A.2.4. Obtain Authorization information
As described in Section 3.4, the authorization of an entity requires
several steps. The authorization information must be configured by
the principal and provided to the enforcing entity.
o Task TObtainSourceAuthz: Obtain authorization information about an
entity from C's principal (COP). Description: COP defines
authorized sources for R. The authorization information must be
made available to C to enable it to enforce COP's authorization
Gerdes Expires April 1, 2016 [Page 17]
Internet-Draft ace-tasks September 2015
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.
Requirements: * RqObtainSourceAuthz.1: Must be performed by an
entity which is authorized by COP. * RqObtainSourceAuthz.2: Must
be performed by an entity which is authorized to speak for COP
concerning authorized sources for R. * RqObtainSourceAuthz.3:
Should be performed by a device which can provide some sort of
user interface to facilitate the configuration of authorization
information for COP. Preconditions: * PreObtainSourceAuthz.1: COP
configured authorized sources for R (see Appendix A.2.6).
Postconditions: * PostObtainSourceAuthz.1: C obtained S'
authorization to be a source for R (fulfills PreValSourceAuthz.1,
see Appendix A.2.2).
o Task TObtainAccessAuthz: Obtain authorization information about an
entity from S' principal (ROP). Description: ROP 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. Requirements: * RqObtainAccessAuthz.1: Must be
performed by an entity which is authorized by ROP. *
RqObtainAccessAuthz.2: Must be performed by an entity which is
authorized to speak for ROP concerning authorization of access to
R. * RqObtainAccessAuthz.3: Should be performed by a device which
can provide some sort of user interface to facilitate the
configuration of authorization information for ROP.
Preconditions: * PreObtainAccessAuthz.1: ROP configured
authorization information for the access to R (see
Appendix A.2.6). Postconditions: * PostObtainAccessAuthz.1: S
obtained C's authorization for accessing R (fulfills
PreValAccessAuthz.1, see Appendix A.2.2).
A.2.5. Attribute Binding
As described in Section 3.3, several steps must be conducted for
authentication. This section addresses the binding of attributes to
a verifier.
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.
Gerdes Expires April 1, 2016 [Page 18]
Internet-Draft ace-tasks September 2015
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.
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.
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).
o Task TValSourceAttr: Validate on the client side that an entity
has certain attributes. 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. Requirements: *
RqValSourceAttr.1: Must be performed by an entity which is
authorized by COP to validate claims about S. *
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). Postconditions: * 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 Appendix A.2.2 and
PreSecureComm.1, see Appendix A.2.3).
o Task TValReqAttr: Validate on the server side that an entity has
certain attributes. 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. Requirements: *
RqValReqAttr.1: Must be performed by an entity which is authorized
by ROP to validate claims about C. * 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).
Postconditions: * PostValReqAttr.1: Means for authenticating
(validating the attribute-verifier-binding of) other entities were
given to S in form of a verifiable endorsement (fulfills
Gerdes Expires April 1, 2016 [Page 19]
Internet-Draft ace-tasks September 2015
PreValSourceAuthz.2, see Appendix A.2.2 and PreSecureComm.1, see
Appendix A.2.3).
A.2.6. Configuration of Authorization Information
As stated in Section 3.4, several steps have to be conducted for
authorization. This section is about the configuration of
authorization information.
The principal of an endpoint or resource wants to be in control of
her device and her data. For that purpose, she has to configure
authorization information. COP might want to configure which
attributes an entity must have to be allowed to represent R. ROP
might want to configure which attributes are required for accessing R
with a certain action.
o Task TConfigSourceAuthz: Configure for C authorization information
for sources for R. Description: COP has to define authorized
sources for R. Requirements: * RqConfigSourceAuthz.1: Must be
provided by COP. Postconditions: * PostConfigSourceAuthz.1: The
authorization information are available to an endpoint which
performs TObtainSourceAuthz (fulfills PreObtainSourceAuthz.1 see
Appendix A.2.4).
o Task TConfigAccessAuthz: Configure for S authorization information
for accessing R. Description: ROP has to configure if and how an
entity with certain attributes is allowed to access R.
Requirements: * RqConfigAccessAuthz.1: Must be provided by ROP.
Postconditions: * PostConfigAccessAuthz.1: The authorization
information are available to the endpoint which performs
TObtainAccessAuthz (fulfills PreObtainAccessAuthz.1, see
Appendix A.2.4).
Author's Address
Stefanie Gerdes
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63906
Email: gerdes@tzi.org
Gerdes Expires April 1, 2016 [Page 20]