Subject: [Ace] Fwd: New Version Notification for draft-gerdes-ace-actors-03.txt

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 10 Mar 2015 14:25:29 +0100

Hi all,

Please find attached the new version notification for the actors draft.

The main changes are:
- To address comments (e.g., in the ACE session in Honolulu) OAuth 
terminology was removed to avoid misunderstandings.
- The term "owner" was replaced since comments on the list indicated 
that owner might not be a suitable term.
- A section about autonomous communication was added to point out that 
there is not always an active user in constrained environments, and 
devices need to be able to enforce the user's security policies 
autonomously.

Comments are very welcome.

Thanks,
Steffi

-------- Forwarded Message --------
Subject: New Version Notification for draft-gerdes-ace-actors-03.txt
Date: Mon, 09 Mar 2015 16:49:20 -0700
From: [email-masked]
To: Stefanie Gerdes <[email-masked]>, Stefanie Gerdes <[email-masked]>

A new version of I-D, draft-gerdes-ace-actors-03.txt
has been successfully submitted by Stefanie Gerdes and posted to the
IETF repository.

Name:		draft-gerdes-ace-actors
Revision:	03
Title:		Actors in the ACE Architecture
Document date:	2015-03-09
Group:		Individual Submission
Pages:		26
URL: 
http://www.ietf.org/internet-drafts/draft-gerdes-ace-actors-03.txt
Status:         https://datatracker.ietf.org/doc/draft-gerdes-ace-actors/
Htmlized:       http://tools.ietf.org/html/draft-gerdes-ace-actors-03
Diff:           http://www.ietf.org/rfcdiff?url2=draft-gerdes-ace-actors-03

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.  Based on the tasks, an
    architecture is developed to represent the relationships between the
    logical functional entities involved.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Göran Selander <[email-masked]>
Date: Tue, 17 Mar 2015 10:59:45 +0000

Hi Steffi,

I've finally got around to read the "actors" draft as a whole. I've listed
some comments below.

General:

• The draft introduces one new node in the architecture (compared to e.g.
UMA) called COP, supporting a constrained client. I think this kind of
"support node" is useful, but its functionality needs to be further
elaborated (see detailed comments).

• There is lots of innovation of terminology; both new terms
(authenticated authorization, binary authorization, unrestricted
authorization, authorized representation, authorized resource, endorsement
information, complexity levels, etc.); new names for roles in the
authorization architecture (Client Overseesing Principal, Server
Overseeing Principal, Client Authorization Manager, Server Authorization
Manager, Attribute Binding Authority); and also the meaning of existing
terms (e.g. authorization) is being changed. I disagree with how some
terms are used and moreover I think it would be much better to use less
terminology and try to reuse existing terminology. Here are a few reasons:

	- Access control is not a new problem. Although the constrained
environment motivates some new functionality, that does not warrant a
completly new terminology.

	- At the end of the day we want people approaching this work to be able
to reuse gained knowledge from other contexts to quickly understand what
this work is good for. The sheer amount of new terms is discouraging.

	- Taking existing terminology as a basis doesn't necessarily imply
restricting the solution (as has been iterated many times on this list,
see also detailed comment below). Besides, in our case it is mainly a
question of *adding* a few terms such as describing the functionality of
the above mentioned support node. (Of course, for that purpose, one new
term will be needed.)

• There is an ambition to symmetrize the problem statement and remove the
intrinsic assymmetry of the access control problem. However aesthetic this
architecture looks in all its symmetry and matching terminology, this
ambition is misguided and hides part of the problem. I suspect it is this
ambition which is behind the re-interpretations of existing terms, such as
"authorization". For example only confidentiality and integrity aspects of
authorization are considered  ("The security objectives that can be
addressed by an authorization solution are confidentiality and integrity")
since those can be handled more symmetrically than other aspects of
authorization. More below.

• The end-to-end security setting as described in e.g.
draft-selander-ace-object-security, is missing from in this draft. (See
below)

Detailed comments:

Section 1.1
—

• "Actor"

I would call this "role". There is a common use of the terms "actor" and
"role", wherein a "role" characterizes certain functionality and an
"actor" is some entity that may or may not have the functionality
characterised by the role.

"Resource Overseeing Principal (ROP):
Client Overseeing Principal (COP):
Server Authorization Manager (SAM):"

These terms have 

Section 2
—

• "authorized representation"

This term is not defined in the terminology section but supposedly means a
representation the client is configured to send in a particular request

• "authorized resources"

This term is not defined in the terminology section but supposedly means a
resource that a client is configured to request

• "Req.0.2    C is exchanging status updates of a resource only with
      authorized resources."

That the use of the term authorization on the client side is misleading.
Every task a client performs is on behalf of its control node (COP). If
all these tasks are called authorization, then there is nothing that isn't
authorization.  There is no system resource on the client side to which
access is authorized.

Section 3
—

• "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. "

I agree that confidentiality and integrity protection can be used as one
component to enforce an authorization decision, but characterizing
authorization only as that is misleading. Generally speaking,
authorization is about restricting access to (system) resources, which
include restricting the right to initiate processing on a server, which in
turn provides some resistance against attacks/overload and thus is related
to availability.

• "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. "

Why does C need to integrity protect transmitted data? Isn't it sufficient
that S integrity protects the sensor value representation it is hosting?

Section 4
—

• "To determine if an entity is authorized to access a resource, an
authentication mechanism is needed. According to the Internet Security
Glossary [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. "

Authentication, in the sense of verifying a claim about a attribute value,
is not necssary. A server may encrypt a resource representation with a
specific key only possessed by authorized clients (cf. OSCAR,
http://arxiv.org/abs/1404.7799).

• "We use the term authenticated authorization to refer to a synthesis of
mechanism for authentication and authorization. "

The term "Authenticated authorization" is quite vague.

• "unrestricted authorization"

This is defined as "no authorization". Why not just say so?

• "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."

I find a several things confusing here:
	- What party is the authorizing party? A server or a SAM / Authorization
Server?

	- "Authentication is therefore required for messages that contain
representations of an accessed item. " The next sentence claims to make
precise, but does so in terms of authorization.

	- "the authorizing party needs to make sure that (- - -)the sender of a
message containing a representation are authorized to (- - -) send this
message". I think this had better be rephrased as the CAM enables
configuration of the client.

• "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."

The formulation indicates that the decision whether a client that makes a
request is needs to take into account server policies before encrypting
the request. I think this should be configured in the client.

Section 6
—

6.1

• "This document does not assume a specific solution."

This is two-edged sword. If you claim that we can't use OAuth/UMA
architecture because it assumes a specific solution, then so does this
document.

6.2

• "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. 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."

I think this is all very complicated, and is overusing the term
"authorization". The server should determine if the client is authorized
to access a resource, and perform accordingly. The client should perform
as configured (potentially dynamically using a CAM-type node). That's it.

6.4

item 1: I think this is out of scope for ACE
item 2: agree. I think we should add something analogous about
configuration of client
item 3-4: this is assuming a particular solution. We can obtain
granularity without the attribute exercise by associating certain keys to
certain permissions, as mentioned above.

7.1

"C performs the following tasks:
• Negotiate means for secure communication (Task TSecureComm, see Appendix
A.2.3)."

Not necessary if there is a TTP, such as an Authorization Server,
providing security context

• "Validate that an entity is an authorized source for R (Task
TValSourceAuthz, see Appendix A.2.2)."

I would phrase this that C is configured to request R.

"S performs the following tasks:
• Negotiate means for secure communication (Task TSecureComm, see Appendix
A.2.3)."

Not necessary if there is a TTP, such as an Authorization Server,
providing security context

7.2

"COP must fulfill the following task:
• Configure for C authorization information for sources for R "

I would rephrase this bullet as "• Configure for C resources R to be
accessed"

7.3

•  Why does the CAM have to be in the same security domain as C and COP.
Could it not be outsourced? (See e.g. Healthcare scenario
http://kantarainitiative.org/confluence/display/uma/UMA+Trust+Model+User+gu
ide)

• The setting with CAM always being intermediary between C and SAM
(=Authorization Server) is problematic. C needs to be authorized (and/or
prove that it is) to access S. In a federated setting it could work that,
as CAM becomes authorized so does all its assigned Cs. But in the general
case, SAM needs to communicate securely with C and provide the necessary
keys or credentials. In this case CAM has no security function. But the
architecture prescribes that interaction between C and SAM is never done
directly, but via CAM. In this case CAM does not have a role at all, so
there is not only a difference where CAM is hosted, but in its function.

8.1

• Next to last paragraph: Although confidentiality and integrity
protection are the security objectives considered in this document, there
is no consideration of end-to-end security in the presence of intermediary
nodes (which would induce DTLS hop by hop)

8.2

• In case OAuth is applied to the "less constrained level", what are the
protected resources at SAM accessed by CAM? (Access tokens?)

Best regards
Göran

On 2015-03-10 14:25, "Stefanie Gerdes" <[email-masked]> wrote:

>Diff:           
>http://www.ietf.org/rfcdiff?url2=draft-gerdes-ace-actors-03
>
>Abstract:
>_______________________________________________
>Ace mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ace

---

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 24 Mar 2015 16:42:21 +0100

Hi Göran,

Thank you for your comments.

> elaborated (see detailed comments).

In fact there are two supporting nodes called CAM and SAM. They both 
help their respective constrained device with authentication and 
authorization since the constrained devices might be too constrained to 
perform complex security tasks on their own, e.g. storing a large number 
of keys or interpreting complex authorization policies. Moreover, CAM 
and SAM provide user interfaces which the constrained devices might not 
have.

> terminology and try to reuse existing terminology. Here are a few reasons:

I find it surprising that you seem to think that the actors draft 
redefines authorization. The common understanding is that authorization 
is about allowing entities to do or be something. Do you question that?

I agree that we should use exisiting terminology where applicable. I am 
not aware that there are definitions for the levels of granularity for 
the authorization such as "binary authorization", "device authorization" 
etc. elsewhere. If there is, please point it out to me.

> completly new terminology.

People found the OAuth terminology in the draft confusing which is why 
it was removed. I think it will be more damaging to use a terminology 
that doesn't really fit.

> this work is good for. The sheer amount of new terms is discouraging.

Not being able to understand the underlying problems because the 
terminology indicates a different solution will only make things worse.

> the above mentioned support node. (Of course, for that purpose, one new

True, existing terminology not necessarily implies restricting the 
solution and I am a fan of reusing terminology where it fits. I didn't 
get the impression that the existing terminology fits so well with the 
architecture proposed in the actor's draft and from earlier comments I 
got the impression that other people share this impression.

> authorization. More below.

I don't understand what you refer to with "symmetrize". I agree that 
there are different security objectives on the both sides (client side 
and server side). That's why we need to modelize them. Only then will we 
be able to see all the problems. If we only model the server side, 
client side problems will be difficult to see.

It would be really nice if you could state which kind of problems are 
hidden in the actor's draft. I was already asking you to point them out 
to me for the use cases document. But unfortunately, you were not able 
or willing to do so until now. It will be difficult to address your 
comment if you are not explaining it.

> draft-selander-ace-object-security, is missing from in this draft. (See

The tasks address the use of proxies (entities that are authorized to 
speak for ..). Is that what you are aiming at?

> characterised by the role.

The term "role" is quite confusing for authorization solutions since it 
will easily be mixed up with the roles in role based authorization. 
There was already so much confusion about the term "resource" that I 
would rather not use the term "role".

> resource that a client is configured to request

I don't get what you are trying to tell me with these comments.

> authorization.  There is no system resource on the client side to which

I don't know what your interpretion of authorization is. The handbook of 
applied cryptography defines it as the "conveyance, to another entity, 
of official sanction to do or be something".

To achieve the security objectives of the client overseeing principal, 
the client must be able to enforce them. It needs to be able to answer 
the question "Does my principal think that this resource on this server 
is an authorized resource or not". Otherwise the security objectives 
integrity and confidentiality are threatened.

The authorization problems on the client side won't go away if we 
pretend that they are not there or try to define them away.

> turn provides some resistance against attacks/overload and thus is related

It might be useful to point out that authorization might also be used 
for load control.

Integrity and confidentiality have a direct dependency to authorization. 
If the authorization solution is broken, the integrity and 
confidentiality of data likely is compromised. I agree that you might 
also use authorization for load control, but availablity is not 
necessarily breached if the authorization solution fails.

> that S integrity protects the sensor value representation it is hosting?

The integrity-protection won't work if C doesn't check the protection of 
the received data. I will rephrase this part to make it easier to understand

> http://arxiv.org/abs/1404.7799).

This is an example for authentication and authorization working closely 
together. You can do authorization and authentication together if you 
bind authorization information to a key. But you will still need to make 
sure that the key is given to the right entity. You can't do 
authorization if you are not sure who you are authorizing and if you 
cannot decide if the one you are talking to really is the one who is 
authorized.

> The term "Authenticated authorization" is quite vague.

Can you elaborate that? I think the paragraph shows why authentication 
and authorization mechanism need to work together.

> This is defined as "no authorization". Why not just say so?

If unrestricted authorization is used, no authorization mechanism is 
used. Therefore everyone is authorized. "no authorization" might be 
misinterpreted.

> 	- What party is the authorizing party? A server or a SAM / Authorization

The client or the server. If the term "authorizing party" is confusing I 
can try to rephrase the section without using it.

Summarizing, the section states that the receiver of a resource 
representation needs to make sure that the sender of the resource 
representation is allowed to send it and that the sender of a resource 
representation must make sure that the receiver of a resource 
representation is allowed to receive it.

> precise, but does so in terms of authorization.

I don't understand this comment.

> configuration of the client.

I think configuration is a very vague term and can mean everything in 
this context. The problem that we need to solve here is an authorization 
problem.

> the request. I think this should be configured in the client.

I think it will be difficult to configure in the client what a server 
that belongs to someone else wants. I think it will be useful to assume 
that in some scenarios you will always need at least binary 
authorization on the client side.

> architecture because it assumes a specific solution, then so does this

It might be helpful if you also state the context of this sentence. This 
refers to the exchanged messages between the client and the server which 
is stated in the next sentence.

> as configured (potentially dynamically using a CAM-type node). That's it.

With "configure" you mean the configuration of authorization on the 
client side, I guess.

> item 1: I think this is out of scope for ACE

The process of configuration might be out of scope but it is still a 
necessary process. In constrained environments it is necessary to 
consider how this configuration can occur since constrained devices 
often don't have user interfaces or displays.

> item 2: agree. I think we should add something analogous about

No need for that. This already applies to both the client and the server.

> certain permissions, as mentioned above.

I guess you are referring to item 3. I will try to rephrase it to better 
include those solutions.

The authorization will still need to be enforced as defined in item 4.

> providing security context

If a device wants to communicate securely, it somehow hast to obtain the 
means (e.g. keying material) for that. If the Authorization Server 
provides this to the device this fulfills TSecureComm.

> I would phrase this that C is configured to request R.

You mean that you can make sure that an S is an authorized source for R 
by configuring C to access R on S? That would be one solution.

> providing security context

If the authorization provides this to the device, this is TSecureComm.

> http://kantarainitiative.org/confluence/display/uma/UMA+Trust+Model+User+gu

What do you mean with outsourced? That the principal controlling C is 
different from the principal that controls CAM?

> there is not only a difference where CAM is hosted, but in its function.

I don't quite understand what you are getting at. There may be cases 
where you don't need a distinct CAM. You can have a single machine or a 
single piece of software that performs CAM's and SAM's tasks. That's why 
the draft states: "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."

> nodes (which would induce DTLS hop by hop)

What do you think is missing here?

> protected resources at SAM accessed by CAM? (Access tokens?)

I think finding out how constrained level and less-constrained level 
protocols can work together is one of the challenges in ACE. I hope we 
will find out how we will do this exactly but I don't think this is in 
scope for the actor's draft. The draft just states that there are 
different requirements for the different levels.

Best regards,
Steffi

-- 
Stefanie Gerdes			Tel: +49 421 218 63906
TZI Universität Bremen		E-Mail: [email-masked]
Bibliothekstr. 1, MZH 5150
28359 Bremen, Germany

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 24 Mar 2015 10:54:02 -0500

Stefanie Gerdes wrote:
> I don't know what your interpretion of authorization is.

Yesterday in the side meeting, it seemed Göran wants to use
authorization as a synonym for "things you can do with an access control
list", i.e. access control to resources on a CoAP server.  But then
there were some audience comments that you actually can use ACLs to do
authorization of client behavior as well.  So yes, there is some
confusion here.

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Tue, 24 Mar 2015 21:49:58 +0000

Hi Steffi,

I interpret the outcome of the meeting that Ludwig, you and I should
collaborate on drafting a document containing the architecture, terms and
problem statement according to the side meeting results from yesterday and
document that together with parts of the actors draft and the problem
description draft. 

I propose we take the continued discussion offline to save the poor ears
of the ACE members.

Best regards,
Göran

On 2015-03-24 10:42, "Stefanie Gerdes" <[email-masked]> wrote:

>>> Status:        
>>>https://datatracker.ietf.org/doc/draft-gerdes-ace-actors/

---

From: Göran Selander <[email-masked]>
Date: Tue, 24 Mar 2015 21:54:44 +0000

Hi Carsten

On 2015-03-24 10:54, "Carsten Bormann" <[email-masked]> wrote:

>list", i.e. access control to resources on a CoAP server.

This formulation doesn’t ring a bell. And we’ve had the terminology
discussion for quite a while now, let’s not reopen it.

Best regards,
Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 25 Mar 2015 06:51:31 +0100

Hi Göran,

I would still like to know your answers to the questions that are not 
about C, RS, Authorization Managers and Owner Terminology.

Best regards,
Steffi