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

From: Stefanie Gerdes <[email-masked]>
Date: Sun, 19 Jul 2015 22:38:58 +0200

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 
>