[Ace] Review of actors draft

[Samuel Erdtman <[e-mail]>]

Hi,

Review is based on https://tools.ietf.org/html/draft-ietf-ace-actors-01

I absolutely do not want to be rude but the actors draft contributed more
to my confusion then to my understanding. This might be a lack in me but
IMHO the document needs to be reworked before becoming useful, sorry for
saying it. It might be better to spend the energy on the solution drafts
instead of reworking this into a useful state.


== General comments
The text is written with lots of parantheses, IMHO that makes the text
harder to read.

I don’t like the we-statements, this is of cource a subjective opinion but
i prefer specifications to be written in a more neutral form.

The text feels quite academic and unnecessarily complex, from my point of
view readably is very important I some times had to read paragraphs several
times to get what they meant (this could of cource once again just be me,
english is not my native language but I usually get things)

This might be do to my lack of understanding but I cannot se the point with
CAS I think it adds unnecessary complexity without any added value.
Could I get a practical example, I can easily envision the AS being a
server managing policies and access rules on who can access what and lists
of resources but I have a hard time getting a picture of a CAS.
With CAS it is hard to see how RS and C gets a common point of trust, I am
therefor is in favour of just AS that serves both C and RS.
I think that what is included in CAS should be split up into AS and C. I
think that by taking things from AS and C and putting it into CAS the
description of things become complicated and it is hard to understand how
things are connected.

The constrained device limitations are mentioned again and again in the
document but seldom with specific connection to the problem e.g is never
says to limit code since one should use this technology, it is alway these
are the constrains and then comes the list (processing power, memory,
non-volatile storage, etc) and after that a choice but seldom or never a
direct connection. for an example look at “6.  Kinds of Protocols”




>From here on comes a list of comments on small and large things in the
text, As mentioned previously I don’t think the document is ready to be
taken to RFC level and that is visible in the amount of comments. Many of
the comments are questions as a result of the text being hard to read for
me.



1.  Introduction
I think the section is to long and with sections that is a bit to general.


“Without appropriate security mechanisms attackers might gain control
   over things relevant to our lives.”
What is ment by “relevant to out lives”? will it hurt us physical? will it
be problematic integrity wise? It is nuclear to me what is meant hear. My
first interpretation was that it was privacy that was the problem but when
I read it again I was not so sure.

“(for example, it may be
   sufficient to authenticate the age of an actor, so no identifier is
   needed or even desired)”
This example does not feel very IoT connected, I would rather have an
example that authenticates the user as an employee of a company but not the
specific person.

“Moreover, several use cases illustrate the need for fine-grained
   access control policies, for which for instance a basic access
   control list concept may not be sufficiently powerful.”
What use cases? I guess it refers to the use case document, if so a
reference two it would be appreciated


1.1.  Terminology
“Client (C):  An entity which attempts to access a resource on an RS.”
change to
“Client (C):  An entity which attempts to access a resource on a RS.”

“Authorization Server (AS):  An entity that prepares and endorses
      authentication and authorization data for a Resource Server.”
“Client Authorization Server (CAS):  An entity that prepares and
      endorses authentication and authorization data for a Client.”
I might be stupid but I don’t get the description, maybe a few more words
could make it clearer.

“Authenticated Authorization:  A synthesis of mechanisms for
      authentication and authorization.”
Once again i don’t get it, why is this term needed here? could it be
explained a bit more.

“Note that other authorization architectures such as OAuth [RFC6749]
   or UMA [I-D.hardjono-oauth-umacore] focus on the authorization
   problems on the RS side, in particular what accesses to resources the
   RS is to allow.  In this document the term authorization includes
   this aspect, but is also used for the client-side aspect of
   authorization, i.e., more generally to describe allowed interactions
   with other endpoints.”
I agree that UMA and OAuth2 focuses on the authoriztion of the client to
access a resource at RS but they do not leave client to chance, in the
original context of OAuth2 and UMA the endpoints are more powerful and the
authentication of the server is offloaded to TLS and the CA list of the
involved clients. In UMA and OAuth2 the client will not accept a RS if it
does not trust its certificate. I agree that we in this environment need to
give the client more help on this part but I think this statement is a bit
simplified.


2.  Architecture and High-level Problem Statement
Absolutely not necessary but it looks better and is usually good to have a
section introduction.


2.1.  Elements of an Architecture
“The following
   setting is assumed:”
How does these release to the whole chapter “8.  Assumptions and
Requirements”, there is no referens to it from here, I prefer the text from
this section.

“To reuse OAuth and UMA
   terminology, the present document calls C's controlling principal the
   Requesting Party (RqP), and calls RS's controlling principal the
   Resource Owner (RO).”
It might be correct that the RqP takes authorisation decisions for the
client but it feels quite contra intuitively so some more explanation of it
would be appreciated.



2.3.  Information flows
This section show that to allow initiation of communication from either of
the two endpoint they would need to both act as RS and C. with the section
title I expected more details on each arrow. I also feel that what is in
the section is a bit abundant as it is now, it mostly complicates things
that can be implicitly understod I have not seen the HTTP specification
saying that if the server would like to communicate with the client the
client also needs to deploy a server.


2.4.  Problem statement
“The interaction between potentially constrained endpoints is
      controlled by control information provided by less-constrained
      nodes on behalf of the principals of the endpoints.”
Is this really a problem? To me this sounds more like a solution

“control information”
new concept, is it the same as authorization information? should it maybe
be mentioned in the terminology list.


3.  Security Objectives
“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 guess this refers to a denial of service (DOS) attack, maybe that could
be mentioned, it would very quickly put it in a security context by just
mentioning the word.

“if RqP requires the integrity of representations of a
   resource R that RS is hosting, both C and RS need to partake in
   integrity-protecting the transmitted data.”
Why does C need to participate? is it because it validates the returned R
from RS before presenting it to RqP? if thats it I’m okay with that but one
again could be clearer.

“Moreover, RS needs to
   protect any write access to this resource as well as to relevant
   other resources (such as configuration information, firmware update
   resources) to prevent unauthorized users from manipulating R.”
What is this sentens trying to say? Is it referring to physical tampering?
or is it again the integrity and confidentiality of the data returned
and/or received? Or is it that RS needs to verify all wire access, i.e.
incoming data?


3.1.  End-to-End Security Objectives
“Note that there may also be cases of intermediary nodes that very
   much partake in the security objectives to be achieved.”
It is a bit unclear what these cases may be, is that intentional? or did
you not find any?


“What is the
   endpoint to which communication needs end-to-end protection is
   defined by the use case.“
What use case? a general use case or one from the use case document or a
potential use case?


4.  Authentication and Authorization
This whole section is very unspecific and adds very little to the IoT
setting it mostly speaks of Authentication and Authorisation in general
terms so it could probably be shortened to a third without losing much
valuable information for the context.

5.  Actors and their Tasks
“This section provides a more
   detailed description of the various "actors" in the architecture”
Why is actors within quotation marks? is it not really actors in the
architecture? if not what is it then?

“the
   logical functional entities performing the tasks required”
The tasks required for what? secure communication? authorisation? something
else?


5.1.  Constrained Level Actors
“Validate that an entity is an authorized server for R.”
Does this mean that C validates the identity of RS or that it validates the
integrity of a response form RS i.e. R?

“For simplicity of exposition, these resources are described as if
   they had separate RS.”
What does this relate to I see no further descriptions that this is
relevant for so I would just skip this sentence.


5.2.  Principal Level Actors
I think there need to bee more motivation for why and how RqP decides on
the communication security required between C and RS. In practice RpQ will
not take any decisions it will be based on the system setup in the same way
as you don’t look at all your TLS handshakes when you surf the web then you
just accept that the browser comes bundled with a set of good CAs. In this
setting it will probably have be a more dynamic setup where AS will inform
C how to communicate with RS instead of as on the web there is one size
fits all, TLS.


5.3.  Less-Constrained Level Actors
I think this section becomes problematic since I don’t think CAS adds value
just complexity

7.1.  Authorization
“AS needs to transfer authorization information to RS and CAS needs
      to transfer authorization information to C.”
And how does CAS and AS relate to each other so that the authorisation
information transfered to RS and C is compatible? Once again I thin CAS
adds more complexity then value.


7.4.  Cryptographic Keys
Does this section at all belong in this draft

7.4.  Cryptographic Keys
Symmetric vs Asymmetric Keys
feels half done, with the unanswerd question and the headline is like a
question but with no answer

7.4.  Cryptographic Keys - Key Establishment
I like the reference to the use case document, that is missing in the rest
of the document


8.1.  Architecture
Architecture is defined again? is that really necessary?


8.2.  Constrained Devices
“All devices under consideration can process symmetric cryptography
      without incurring an excessive performance penalty.”
Then there is two bullets that AES is used and for super constrained
devices SHA256, that is two completely different things, that does not
solve the same problem further one could agree that for super constrained
devices we can only do integrity protection and the use a MAC algorithm
i.e. not SHA256 but HMAC with SHA256.


8.7.  Resource Access
“Resources are accessed in a RESTful manner using GET, PUT, POST,
      DELETE.”
Feels like a technology choice that maybe should not be done in this
document, I think it unnecessarily limits where the architecture could be
used.

“By default, the response to a request needs to be integrity
      protected and encrypted end-to-end from RS to C.  It needs to be
      possible for C to detect a replayed response.”
Encryption does not necessarily provide integrity protection

8.8.  Keys and Cipher Suites
Here comes a new concept authorization manager, do we need it? if yes mate
we should have it in the terminology section.



Best Regard
Samuel Erdtman