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

From: "Jim Schaad" <[email-masked]>
Date: Sun, 9 Aug 2015 19:35:35 -0700

I glanced at the -03 version.  It did a better job of separating things in section 2.1.  I would suggest restoring that structure.

> -----Original Message-----
> From: Stefanie Gerdes [mailto:[email-masked]]
> Sent: Sunday, July 19, 2015 1:39 PM
> To: Jim Schaad
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Ace] draft-gerdes-ace-actors
> 
> Hi Jim,
> 
> I think that the -03 version [1] of the draft addressed a lot of the issues you are
> mentioning. It had a clear focus, listed the tasks and explained the need for the
> different actors.
> 
> Best regards,
> Steffi
> 
> [1] https://tools.ietf.org/pdf/draft-gerdes-ace-actors-03.pdf
> 
> Am 19.07.2015 13:20 schrieb Jim Schaad <[email-masked]>:
> >
> > 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.
> >
> > 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.
> >
> > * Should "endpoint" be part of the terminology section?
> >
> > 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.
> >
> > *  Why do you have information flows as one directional between CAS and C?
> >
> > 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)
> >
> > *  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.
> >
> > ****
> >
> > I am tired and going to stop at this point.
> >
> > Jim
> >
> >
> >
> > _______________________________________________
> > Ace mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ace
> >