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

From: "Jim Schaad" <[email-masked]>
Date: Sun, 19 Jul 2015 13:20:58 +0200

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

---

From: Göran Selander <[email-masked]>
Date: Sun, 19 Jul 2015 14:53:55 +0000

Jim, thanks for reviewing, some first comments below.

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

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

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

>Times

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

>somebody.  These are different authentication models.

Does section 7.2 address your questions?

>_______________________________________________
>Ace mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ace

---

From: Göran Selander <[email-masked]>
Date: Tue, 21 Jul 2015 16:25:38 +0000

Jim,

Again, thanks for your detailed review! Since the editor of the document,
Carsten, has been very busy, the other authors have compiled the following
replies to your comments. (Thanks also to Olaf for good input.)

>pieces are given but not anything representing a complete picture.

The intention was that not only some elements but "all the elements an
actual 
Architecture can comprise of”. We change this.

>discuss how authorization would be dealt with.   This statement could be

Access control lists is mentioned in more than one place, exactly which
statement are you referring to (or is it the whole paragraph)?

The point we are trying to make is that the use of static authorisation
does not suit all use cases in particular due to the nature of constrained
device deployments with built-in devices, long deployment times etc., and
therefore especially in this case we need to consider dynamic updates of
authorization policies.

>someplace so I can verify this for myself.

Point taken. We will add some examples and reference another draft that
will specify tasks in detail (to be written).

>Also, for many of these tasks it

True. There may various reasons for offloading. We should rephrase this
text to reflect
thatc.

>can and cannot be placed together and having such a list would be helpful

OK. The task description mentioned previously should address this comment
too.

>* Doing forward references to fulfill some of these requests is perfectly

OK.

>for client-side authorization.

OK, we should clarify this paragraph.

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

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

>endpoint cannot host the functionality of AS and CAS as well so this

Right, we change that.

OLD
o  An endpoint may host functionality of C, RS or both C and RS.

NEW

		

						   o  An endpoint may host functionality of one or more actors.

>introduction before you start.

Good catch. We will make a forward reference where both the term and its
security objectives are described.

>either a neutral party or the AS that is being talked to.

The CAS has both the support and control function. We will explain this
better.

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. We will remove the
reflection from the figure.

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

The figure is intended to illustrate, on a high level, the relevant
information flows with constrained devices in scope of ACE. These
information flows can be realised with different protocols so the actual
message flow between the actors may be different, we should explain this
better in the text. But although there may be requests going from C to
CAS, the control information carried in the response in that case is the
information of interest here, and this is the reason for only showing
information flow in one direction.

(This differs from my previous answer to the draft as individual author.)

>* Why do you not talk about the presence or absence of AS and CAS nodes at

Do you mean the intermittent connectivity aspect, i.e. that the CAS or AS
may not available from the respective constrained nodes at times?

>* Store and forward should be discussed in this document. (i.e.

Store and forward is mentioned in the use case draft, section 2.5.3.
(https://tools.ietf.org/html/draft-ietf-ace-usecases-04#section-2.5.3)
What aspect of that do you think should be discussed in this document?

>specifically why we would care about them.

We will provide an example to illustrate why this is useful.

>*  I assume that access is also a security object that is addressed by

Is this in the context of the security objectives, section 2.1? Are you
referring to “availability” in the sense of ensure that entities that are
entitled to get access do get access?

>not a great deal of agreement on its meaning.

OK, we remove the reference to non-repudiation. This is not central in the
current draft.

>somebody.  These are different authentication models.

In section 4 we elaborate on what is being authenticated. The intention is
not to define what is being authenticated but allow different
approaches for different use cases. We should either mention that here or
make a forward reference from paragraph 2 in section 3 to section 4.
Would that address your question?

Göran

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 25 Jul 2015 19:36:11 -0500

> -----Original Message-----
> From: Göran Selander [mailto:[email-masked]]
> Sent: Tuesday, July 21, 2015 6:26 PM
> To: Jim Schaad; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Ace] draft-gerdes-ace-actors
> 
> Jim,
> 
> >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
> >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.
> 
> The intention was that not only some elements but "all the elements an actual
> >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

Paragraph #3 is what I am referring to.  

A better layout for the paragraph is probably to reverse the entire sense of it.

We need authorization - When and how are identities setup. How and why are identities needed to be check.  Some things can be anonymous.  

We need authorization - what are the requirements -
   -  Both gross preconfigured and fine grained.
    - Preconfigured ACLS does gross,  Shared securities does gross.  Other methods are needed for fine-grain.

> 
> The point we are trying to make is that the use of static authorisation does not
> suit all use cases in particular due to the nature of constrained device
> deployments with built-in devices, long deployment times etc., and therefore
> especially in this case we need to consider dynamic updates of authorization
> policies.
> 
> 
> 
> >
> >*  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.
> 
> 
> Point taken. We will add some examples and reference another draft that will
> specify tasks in detail (to be written).
> 
> 
> 
> True. There may various reasons for offloading. We should rephrase this text to
> reflect thatc.
> 
> 
> 
> >
> >* 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.
> 
> OK. The task description mentioned previously should address this comment too.
> 
> 
> 
> >
> >* Doing forward references to fulfill some of these requests is
> >perfectly reasonable.
> 
> OK.
> 
> >
> >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 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.
> 
> 
> Right, we change that.
> 
> 
> OLD
> >*  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.
> 

Things looked slightly better for layout in the previous version where you did different sections (hopefully with some small intro) for each of the different levels that you have here.

> 
> >
> >*  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
> >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.
> 
> 
> The CAS has both the support and control function. We will explain this better.
> 
> 
> 
> 
> >
> >Information Flows
> >
> >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. We will remove the reflection from the figure.
> 
> 
> >
> The figure is intended to illustrate, on a high level, the relevant information
> flows with constrained devices in scope of ACE. These information flows can be
> realised with different protocols so the actual message flow between the actors
> may be different, we should explain this better in the text. But although there
> may be requests going from C to CAS, the control information carried in the
> response in that case is the information of interest here, and this is the reason
> for only showing information flow in one direction.

Given the number of flows that are discussed in doing things like key distribution, not representing requests from the client/resource to the CAS/AS seems to be undesirable.   This is emphasized by the fact that you are frequently talking about off-loading parts of the control decisions from the constrained layer to the controller layer.  This means that the document is discussing this as an information flow on a regular basis.

> >* Why do you not talk about the presence or absence of AS and CAS nodes
> >at Times
> 
> Do you mean the intermittent connectivity aspect, i.e. that the CAS or AS may
> not available from the respective constrained nodes at times?
> 

Yes

> What aspect of that do you think should be discussed in this document?

This document should be readable in the absence of the use case document.  It may or may not get published.  This document should be the first read document for ACE.  If that is the case then this is the type of thing which needs to be included.

> 
> 
> >
> >*  Better description of type 2 security objects needs to be undertaken
> >- specifically why we would care about them.
> 
> Is this in the context of the security objectives, section 2.1? Are you referring to
> “availability” in the sense of ensure that entities that are entitled to get access
> do get access?
> 

Yes - should have been security objective in my statement.

> 
> 
> >
> >*  Kill the term non-repudiation - I don't know what this means and
> >there is not a great deal of agreement on its meaning.
> 
> >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.
> 
> 
> In section 4 we elaborate on what is being authenticated. The intention is not to
> define what is being authenticated but allow different approaches for different
> use cases. We should either mention that here or make a forward reference
> from paragraph 2 in section 3 to section 4.