Re: [Ace] draft-gerdes-ace-actors

[Göran Selander <[e-mail]>]

Jim, thanks for reviewing, some first comments below.

On 2015-07-19 13:20, "Jim Schaad" <[e-mail]> wrote:

>I have read through this draft and my first comment is - I don't
>understand
>what this draft is trying to accomplish.  My confusion begins in the
>second
>paragraph of the abstract where it says that it is providing "elements of
>an
>architecture / a problem statement".
>
>The idea of providing terminology is reasonable - although I generally
>don't
>believe that a standalone document is a good place to do so unless you are
>doing a lot of definitions.  And for the most part you just use the same
>ones as OAuth is using.   I can see providing an architecture that is
>going
>to be reasonable complete or a problem statement.  But doing just elements
>of those is not useful.  How is one to evaluate anything against it if
>just
>pieces are given but not anything representing a complete picture.

Agree. I think this draft should contain both architecture and problem
statement, to the level of detail that it becomes easy for people to
understand what this work is about.


>
>Introduction:
>
>* constrained devices are not the only ones for which ACLs are not
>sufficiently generic.  There are lots of places where doing access control
>is off-loaded from a device to another system.  Even with ACLs you need to
>discuss how authorization would be dealt with.   This statement could be
>much clearer.
>
>*  If you are going to tell me that there are security tasks that cannot
>be
>done, you need to provide a list of what security tasks you care about
>someplace so I can verify this for myself.  Also, for many of these tasks
>it
>is necessary to offload even when they can be done by the device.
>Offloading authorization is not uncommon even for larger devices.
>
>* Just saying that limitations are a problem is not generally helpful.  It
>would be better to list some of the reasons for each security task you
>care
>about.  Since people are going to need to make decisions about what things
>can and cannot be placed together and having such a list would be helpful
>in
>that regard.
>
>* Doing forward references to fulfill some of these requests is perfectly
>reasonable.
>
>Terminology:
>
>*  I am completely lost by the last sentence in this section.  It may be
>signature structure, but it is also an issue with what you are talking
>about
>for client-side authorization.

I understand what you mean. This was a topic of intense discussions during
the spring. The current draft is using “authorization" in a natural
language sense, i.e. any action that the client can be configured to do by
the CAS is considered authorization.

>
>* Should "endpoint" be part of the terminology section?

This is defined in RFC7252, so should be added to the list of terms
referenced in from that.

>
>Architecture:
>
>*  I have a problem with bullet #1 - It may be due to working in SACM and
>depends on how one defines endpoint.  However I see no reason that an
>endpoint cannot host the functionality of AS and CAS as well so this
>bullet
>is not complete.
>
>*  The term "constrained level" pops up out of the middle of nowhere -
>this
>really needs to be defined.  Perhaps this should be a section title with
>and
>introduction before you start.
>
>*  The introduction of the CSA does not seem logical if it is to help make
>requests of the RS.  This needs more justification.  I would have thought
>it
>was there to control the C and what it does with things.   This seemed to
>be
>the Objective type 2 statement from above.   If you are making it a
>support
>item, then it does not make sense either to call it an access control
>point
>or to say it is being controlled by the RqP.  It could just as easily be
>either a neutral party or the AS that is being talked to.
>
>Information Flows
>
>*  I don't understand the reason for complicating the diagram.   Having it
>be the simple version, at least at first presentation of flows, makes it
>easier to understand.  You can talk about the reflection at a later point.

The purpose of this picture was to emphasize that the endpoints can in
general host both client and server functionality, but this is already
explained in text so I agree it can be omitted.


>
>*  Why do you have information flows as one directional between CAS and C?


The main information flow, just as in the case of AS and RS, is from the
less-constrained device to the constrained device. But you are right that
in both cases there may be information flows in the reverse direction.
E.g. The RS may request the AS for an authorization decision given a
specific request from a client.


>
>Missing Architecture issues
>
>* Why do you not talk about the presence or absence of AS and CAS nodes at
>Times
>
>* Store and forward should be discussed in this document. (i.e.
>combination
>of push and pull models)

Different authorization schemes are discussed in
https://tools.ietf.org/html/draft-seitz-ace-core-authz
Are there any schemes you miss there?

>
>*  Better description of type 2 security objects needs to be undertaken -
>specifically why we would care about them.
>
>Security Objectives:
>
>*  I assume that access is also a security object that is addressed by
>authorization.
>
>*  Kill the term non-repudiation - I don't know what this means and there
>is
>not a great deal of agreement on its meaning.
>
> * You absolutely need some measure of authentication involved.  The
>paragraph 2 needs have a cleaner start that what it does.  You really need
>to talk about authentication, are you authenticating the device or are you
>authentication any device (or some set of devices) that are owned by
>somebody.  These are different authentication models.

Does section 7.2 address your questions?

>
>****
>
>I am tired and going to stop at this point.
>
>Jim
>
>
>
>_______________________________________________
>Ace mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ace