Subject: [Ace] some minor comments/suggestions on draft-ietf-ace-actors-03

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Mar 2016 19:53:38 -0400

I read -03 this weekend.
I think that the document begins very well, but we have a lot of work to do
in sections 7/8/9.

I start with some detailed suggestions, and then I kind of get bogged down in
what to do with the later parts.

=====

s/This is particularly applicable to siloed, fixed-purpose deployments./
  This is particularly applicable to siloed, fixed-purpose deployments, and
  is not the subject of this document./
Editorial nit: I think the word "However, " doesn't belong in next paragraph.

add to:
   In order to meet the security
   requirements in constrained scenarios, the necessary tasks need to be
   assigned to logical functional entities.
.. which is the subject of this document.

1.1 the list of terms is not alphabetical, but is presented in order of
    sensible intruction, which I think is *correct*. I think that the fact
    that they aren't alphabetically should be noted.

    ..this document usees the following terminology; in order of importance:

Maybe "importance" is not the correct term.

Principal: move the () to the end of the definition:

   Principal:  An individual that is either RqP or RO or both.
               (Used in its English sense here)

btw: what is the alternative sense?  Does it have a German meaning I'm missing?

2. in the four points, I suggest one additional point:

   o the relationship between C/CAS and RS/AS is pre-established,
     but is out of scope.

2.1:
Change
   o  Objectives of type 2: C is exchanging information with (sending a
      request to, accepting a response from) a resource only where it
      can ascertain that RqP has authorized the exchange with R.

to:
   o  Objectives of type 2: C is exchanging information with (sending a
      request to, accepting a response from) a resource only where R
      can ascertain that RqP has authorized the exchange with R.

with the (), a person reading might have difficulty linking "it" to C or R.

Change:

   (Section 6.2).  (Again, both CAS and AS are conceptual entities
   controlled by their respective principals.  Many of these entities,
   often acting for different principals, can be combined into a single
   server implementation; this of course requires proper segregation of
   the control information provided by each principal.)

to:
   (Section 6.2).  Both CAS and AS are conceptual entities: roles.
   They are controlled by their respective principals.  A multitude
   of CAS and AS roles may be be combined into a single server
   implementation using segregation of control information provided by each
   principal.

I think it's important enough to remove the ().

Change:
   Note also that not all entities need to be
   ready to communicate at any point in time; for instance, RqP may have
   provided enough information to CAS that CAS can autonomously
   negotiate access to RS with AS for C based on this information.

to:
   Note also that not all communications are concurrent or simultaenous;
   for instance, RqP may have provided enough information to CAS during
   provisioning that permits the CAS to autonomously
   negotiate access to RS with AS for C based on this information.

Thank you for including 2.2, architecture variants.
I wonder if it would be worth specific references here to Bananas for Munich?
I think it might also be worth this because in some flows of that use
case, RqP = RO, and sometimes not, and these two situations occur in the
same system.  I'm concerned that someone might read 2.2 and think that
they have to pick *one* of those variants, instead of realizing that
they have to support all roles in some place in their system.

I think that 2.3 makes this pretty clear, but maybe the first paragraph
of 2.3 could be more authoritative?  i.e. we standarized flows and messages,
not devices :-)

   The interaction with the nodes on the principal level, RO and RqP, is
   not involving constrained nodes and therefore can employ an existing
   mechanism.

Would an example or reference be useful here?

   The message flow may pass unprotected paths and thus need to be
   protected, potentially beyond a single REST hop (Section 3.1):

I think that I know what you mean, but I don't like the wording.

   o  We assume that the necessary keys/credentials for protecting the
      control information between the potentially constrained nodes and
      their associated less-constrained nodes are pre-established, for
      example as part of the commissioning procedure.

Yes. I wonder if there is a difference between *provisioning* and
*commissioning*, or if these just two words for the same thing, and if so, if
we (the IETF) should pick one?

   o  Any necessary keys/credentials for protecting the interaction
      between the potentially constrained nodes will need to be
      established and maintained as part of a solution.

Yes, but is this part of it in scope, or is it part of provisioning?
Or to put it differently, is really part of the previous point?

3.1:

change:
   As another example, resource representations sent between endpoints
   may be stored in intermediary nodes, such as caching proxies or pub-
   sub brokers.

to:
   As another example, in order to provide for availability of authorization
   data even when disconnected, resource representations sent between
   endpoints may be stored or cached in intermediary nodes, proxies or
   pub-sub brokers.

change:
   o  To comply with requirements of transparency, a gateway may be
      allowed to read, verify (authenticity) but not modify (integrity)
      a resource representation which therefore also is end-to-end
      integrity protected from the server towards a client behind the
      gateway.

to:
   o  To comply with audit requirements, a gateway may be allowed to read,
      and verify the authenticity of a message, but not modify it.
      The message must be end-to-end integrity protected (server to client).
      The ability to verify mid-way but not change implies that asymmetric
      methods must be supported.

section 4, says:

   Client-side authorization solutions aim at protecting the client from
   disclosing information to or ingesting information from resource
   servers RqP does not want it to interact with in the given way.
   Again, flat authorization (the server can be authenticated) may be
   sufficient, or more fine-grained authorization may be required.  The
   client-side authorization also pertains to the level of protection
   required for the exchanges with the server (e.g., confidentiality).
   In the browser web, client-side authorization is often left to the
   human user; a constrained client may not have that available all the
   time but still needs to implement the wishes of the principal
   controlling it, the RqP.

This paragraph is very hard to parse.  I think that it should read perhaps
read:

   A client has a diversity of types of information, some of which
   may be required to make authorization decisions, and some of which
   may be unnecessary.  A client should not divulge more information
   than the RqP authorizes, and in some cases should not interact at all with
   a particular Authorization Server at all.

   In the browser web, client-side authorization is often left to the
   human user; a constrained client may not have that available all the
   time but still needs to implement the wishes of the principal
   controlling it, the RqP.

   Flat authorization (that is, the server only needs to be authenticated)
   may be sufficient.  In other cases, more fine-grained authorization may be
   required in order for the client to realize that it is authorized to
   communicate with the RS.

{I think that an example of a client that needs to authorize who is talks
to would be a heat/occupancy sensor that is supposed to control the lights.
A light bulb would want to subscribe to updates from the switch, but the
house owner would not want their neighbour's light bulb to subscribe to
updates}

Maybe this section would work better if it covered integrity, authentication,
authorization seperately.  Explaining how clients, resource servers might
need each of those services...

I suggest that:
   Note that actors are a concept to understand the security
   requirements for constrained devices.  The architecture of an actual
   solution might differ as long as the security requirements that
   derive from the relationship between the identified actors are
   considered.

belongs somewhere in the introduction.

Given section 5, I wonder if section 4 is even necessary.
Section 5 needs some more work, but I'm not sure how yet.

Shouldn't 6.1 mention JOSE/COSE?
I didn't get the point of section 6.

Section 7.2: can we link the "in other use cases"
to the actual use cases in 7744?

Section 7.3: is a good discussion, how will we work through the
alternatives?
Section 8: hard to comment.

Section 9: security considerations.
Section 9.1: issue should be: 0, steal the device.
        probably the most important concern is the ability to
        rapidly de-authorize a device, and further, to be able to
        determine if "this is the droid you are looking for"

9.2: I suggest that instead of listing might, might, etc.
that we list in *security considerations* the specific attacks
that are excluded by various kinds of access to clocks.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-