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

From: "Jim Schaad" <[email-masked]>
Date: Mon, 10 Aug 2015 01:29:18 -0700

Forgot to cc the mailing list.

> -----Original Message-----
> From: Jim Schaad [mailto:[email-masked]]
> Sent: Sunday, August 09, 2015 11:19 PM
> To: [email-masked]'
> Subject: draft-gerdes-ace-actors
> 
> Trying to continue my review from before.
> 
> *  I find following the actor abbreviations to be difficult to follow.  It
would be
> easier if the names were reflective of each other.  I am not sure if you
are
> grabbing the names from a different world in which case this probably
cannot be
> done.
> So it would be easier with   C <--> R,  CAS <--> RAS,   CO <--> RO.
Trying to
> figure out that RqP belongs on the C side of the world is somewhat
confusing for
> a first time reader.  Similarly the fact that AS has a prefix for the C
side but not
> the R side is difficult.  As things stand one cannot discuss an AS as a
standalone
> entity which is a generic CAS and RAS item and contrast it with the
differences
> from being on one side or the other.
> 
> *  Section 5, para 2-  Suggest 'an actor is an entity which performs a set
of tasks,
> has a security domain (client domain or resource domain), and a level
> (constrained, less-constrained or principal).'  The second sentence in
this
> paragraph adds no additional detail.
> 
> * Section 5, para 3 - s/for constrained devices/for the architecture/.
The
> second sentence in this paragraph probably wants to say something along
the
> lines of 'An extant architecture can combine multiple actors into a single
physical
> entity.    In this case the combined entity needs to deal with all of the
security
> requirements of the logical actors.
> 
> *  Section 5.1 - As I understand things, the task 'Validate that an entity
is an
> authorized server for R' should be assigned the CAS and not to C.  I could
be
> wrong - it might be assigned to AS.  But it is still not a task for C
> 
> *  Section 5.1 - The last sentence is not making sense to me.  Based on
the
> definition of security domains in section 5, C and RS are always going to
belong
> to different security domains even if the resource owners are the same.
One of
> these needs to be clarified.
> 
> *  Section 5.1 - Kill figure 8 and point to figure 1
> 
> *  Section 5.2 - Why is this your objective?  It might be your model or
> architecture, but it is hardly an objective.
> 
> *  Section 5.2 - para 1 - the last sentence is unclear - do the principals
belong to
> the same security domain or do the principals and their resources belong
to the
> same security domain.  The latter is what seems to be said.
> 
> * Section 5.3 - bullet 3 - who is it doing the negotiation with?  Itself
and C?  that
> is what the text seems to imply
> 
> *  Section 5.3 - Should this section also discuss discovery.  How is C
supposed to
> discover the existence of R and the identity of RS?
> 
> * Section 6.1 - What are the requirements that DTLS considers?  If you
don't tell
> me what the requirements are in this section then there is no reason for
me to
> believe that you have good examples in this section.   Additionally, what
you
> have listed here are just transport protocols.  What about the data that
is going
> to be transported using this protocol?  How do these protocols need to be
> designed?  What levels do the constraints needs to be examined?  Transport
> level?  Security Level?  Data Level?  Discovery
> 
> *  Section 6 is not delivering any useful information.  Either it needs to
have
> information that is needed or it should just be eliminated.
> 
> * Section  7.1 - are you moving authorization information, or
authorization
> decisions from AS to RS?
> 
> * Section  7.1 - What about dealing with authorization information going
> between CAS and AS?
> 
> * Section 7.1 - The second sentence in bullet 3 seems to be misplaced.
> 
> * Section 7.1 - Why is C not enforcing authorization decisions as well?
> 
> * Section 7.2 - bullet 1 - Is there a need for mutual authentication?
> 
> * Section 7.2 - bullet 3 - the second sentence is positing a solution not
a
> requirement.
> 
> * Section 7.2 - bullet 4 - I don't know why this is not written in the
same way as
> bullet 3 - you are just authenticating properties not the entire thing.
> 
> *  Section 8 - I am not sure what the purpose of this section is for.  It
would
> seem to be better to fold this into section 7.
> 
> 
>

---

From: Göran Selander <[email-masked]>
Date: Tue, 11 Aug 2015 05:22:12 +0000

Just commenting on the terminology, which has already has been discussed
for quite some time.

>> grabbing the names from a different world in which case this probably

Yes, all terms except CAS are OAuth/UMA terminology. CAS was coined in
version -04 without any discussion whatsoever in what I believe was an
expression of fatigue over the prior terminology discussion.

>> from being on one side or the other.

I also think the current terminology is unpractical, unaesthetical and
confusing. However, the proposal above does not end the confusion: The ACE
“Resource” may be CoAP “Client”, e.g. in a publish-subscribe setting where
the resource representations are published by to an intermediary message
broker using a CoAP PUT request. In this case the RO is “owning” a Client
and the RAS managing the policies of a Client.

*If* we can motivate inventing our own ACE terminology then one
requirement is to make sure that the new terms avoids this confusion by
decoupling ACE terminology from CoAP/REST terminology, e.g. using
Consumer/Provider instead of Client/Server. But I’m not sure it is worth
the effort. The current terminology (except for CAS) at least has the good
that it is known to a much larger community.

Göran

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 11 Aug 2015 12:19:26 -0700

> From: Göran Selander [mailto:[email-masked]]
> Sent: Monday, August 10, 2015 10:22 PM
> To: Jim Schaad; [email-masked]
> Subject: Re: [Ace] FW: draft-gerdes-ace-actors
> 
> 
> Just commenting on the terminology, which has already has been discussed for
> quite some time.
> 
> 
> I also think the current terminology is unpractical, unaesthetical and confusing.
> However, the proposal above does not end the confusion: The ACE “Resource”
> may be CoAP “Client”, e.g. in a publish-subscribe setting where the resource
> representations are published by to an intermediary message broker using a
> CoAP PUT request. In this case the RO is “owning” a Client and the RAS
> managing the policies of a Client.

I would not be a fan of changing the terminology if it is coming from a world where it is well understood and fixed.   Constantly renaming things is never useful.

I disagree with you about what is happing in the case of a publish-subscribe setting.  The resource that is being discussed is still R, on RS and owned by RO.  What is "wrong" is that figure 1 is incomplete.  There are two different information flows between C and RS that should be documented there.  The first is that which matches a "GET" where the C requests information from RS and RS responds with it.  The second is the case where RS spontaneously provides information to C due to some internal state change.  The latter matches a "PUT/POST" situation.   For both sets of information flow, the set of entities and resources are the same.  Only the way that information flows changes.

However, this does point out that there are several actors which are missing from the document that needs to be discussed.

Data Store - this is a component which is used to hold intermediate results.  Is this a constrained device?  Does it talk constrained and less-constrained protocols?  It can be owned by CO, RO or a third party.  There are interesting security properties.  

Proxy - I am having a hard time understanding CoAP proxies, but it seems that there is a formal method of dealing with going through proxies which change the message being transported.  How does this change the security properties of the message.  One example is that I believe that the destination URL is changed by the proxy and therefore cannot be part of the signed message

jim

> 
> *If* we can motivate inventing our own ACE terminology then one requirement
> is to make sure that the new terms avoids this confusion by decoupling ACE
> terminology from CoAP/REST terminology, e.g. using Consumer/Provider
> instead of Client/Server. But I’m not sure it is worth the effort. The current
> terminology (except for CAS) at least has the good that it is known to a much
> larger community.
> 
> Göran

---

From: Göran Selander <[email-masked]>
Date: Wed, 12 Aug 2015 22:33:44 +0000

On 2015-08-11 21:19, "Jim Schaad" <[email-masked]> wrote:

>> >> *  I find following the actor abbreviations to be difficult to
>>follow.
>> >>It
>> >would be
>>confusing.
>I would not be a fan of changing the terminology if it is coming from a
>world where it is well understood and fixed.   Constantly renaming things
>is never useful.
>
>I disagree with you about what is happing in the case of a
>publish-subscribe setting.  The resource that is being discussed is still
>R, on RS and owned by RO.  What is "wrong" is that figure 1 is
>incomplete.  There are two different information flows between C and RS
>that should be documented there.  The first is that which matches a "GET"
>where the C requests information from RS and RS responds with it.  The
>second is the case where RS spontaneously provides information to C due
>to some internal state change.  The latter matches a "PUT/POST"
>situation.   

And yet another variant is using the CoAP Option “Observe” which allows a
single “GET” request to have multiple responses, e.g. triggered by
internal state change.

>For both sets of information flow, the set of entities and resources are
>the same.  Only the way that information flows changes.

Yes, the ACE entities and resources are the same.  But the CoAP entities
and resources may be different. For example, the Resource Server may be a
CoAP Client, and a Message/Pub-Sub Broker may be a CoAP Server.  The point
I was trying to make was just that for example the term “Client” may be
ambiguous unless it is understood whether it is the ACE entity or the CoAP
entity that is being referred to.

>
>However, this does point out that there are several actors which are
>missing from the document that needs to be discussed.

Various proxies are presented in the CoAP specification and the Pub-Sub
Broker in a separate draft. Some of these are mentioned in section 3.1 but
maybe this needs further elaboration?

>
>Data Store - this is a component which is used to hold intermediate
>results.  Is this a constrained device?  Does it talk constrained and
>less-constrained protocols?  It can be owned by CO, RO or a third party.
>There are interesting security properties.

Good questions. This may be application dependent. At least the option
that it is a third untrusted/untrusting party should be covered. For
pub-sub brokers, the ability to verify that publications originate from a
certain publisher without reading the publication has been mentioned both
in the context of the Pub-Sub Broker draft and ICN applications.

>
>Proxy - I am having a hard time understanding CoAP proxies, but it seems
>that there is a formal method of dealing with going through proxies which
>change the message being transported.  How does this change the security
>properties of the message.  One example is that I believe that the
>destination URL is changed by the proxy and therefore cannot be part of
>the signed message

Proxies specified in CoAP have a defined behaviour. If that behaviour is
predictable by the end-points, then it is possible to define an invariant
which is signed by the sending endpoint and verified by the receiving
endpoint. This applies for example to destination URI (See integrity
protection of CoAP Option “Proxy-Uri" in Appendix A of
draft-selander-ace-object-security).

If the proxy behaviour is not predictable by the end-points, as with e.g.
CoAP Options “Observe" or "Max-Age", then it is not possible to define an
invariant and the corresponding data cannot be integrity protected
endpoint-to-endpoint.

Göran

>>requirement

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 12 Aug 2015 23:34:42 -0700

> Sent: Wednesday, August 12, 2015 3:34 PM
> >> Just commenting on the terminology, which has already has been
> >>discussed for  quite some time.
> >>
> >>
> >> Yes, all terms except CAS are OAuth/UMA terminology. CAS was coined
> >> in version -04 without any discussion whatsoever in what I believe
> >> was an expression of fatigue over the prior terminology discussion.
> >>
> >> may be CoAP “Client”, e.g. in a publish-subscribe setting where the
> >>resource  representations are published by to an intermediary message
> >>broker using a  CoAP PUT request. In this case the RO is “owning” a
> >>Client and the RAS  managing the policies of a Client.
> >
> >publish-subscribe setting.  The resource that is being discussed is
> >still R, on RS and owned by RO.  What is "wrong" is that figure 1 is
> single “GET” request to have multiple responses, e.g. triggered by internal state
> change.
> 
> >For both sets of information flow, the set of entities and resources
> >are the same.  Only the way that information flows changes.
> 
> Yes, the ACE entities and resources are the same.  But the CoAP entities and
> resources may be different. For example, the Resource Server may be a CoAP
> Client, and a Message/Pub-Sub Broker may be a CoAP Server.  The point I was
> trying to make was just that for example the term “Client” may be ambiguous
> unless it is understood whether it is the ACE entity or the CoAP entity that is
> being referred to.
> 

One chooses a terminology and sticks to it.  I there are conflicts then one prefixes the one not used in the current document (i.e. 'CoAP client') or both if it is ambiguous.  You are going to have conflicting terminology no matter what you use, so you chose one and stick to it.  Sometimes it is just a pain.  I had a document where I ended up creating a table of what all of the different protocols called each of the three entities in the architecture draft so that people could follow along.  It made for occasional messy writing, but it made for a much more consistent experience for the reader.

> Various proxies are presented in the CoAP specification and the Pub-Sub Broker
> in a separate draft. Some of these are mentioned in section 3.1 but maybe this
> needs further elaboration?

If they are to be considered part of the standard architecture draft, the absolutely need to be defined here and not in some other place.    I am not seeing a draft which is jumping out as the pub-Sub draft.  But it should probably just be defining protocols and not architecture.  This would be true of other drafts as well.  They can restate a small piece of an architecture, but I expect this draft to cover all of the core/normal items that are going to show up in an architecture.  If I have to read 15 drafts to understand the architecture, I will never be able to do an adequate job of evaluating the security properties and if the solutions are going to actually solve the problem.

> Good questions. This may be application dependent. At least the option that it is
> a third untrusted/untrusting party should be covered. For pub-sub brokers, the
> ability to verify that publications originate from a certain publisher without
> reading the publication has been mentioned both in the context of the Pub-Sub
> Broker draft and ICN applications.
> 
> >
> >Proxy - I am having a hard time understanding CoAP proxies, but it
> >seems that there is a formal method of dealing with going through
> >proxies which change the message being transported.  How does this
> >change the security properties of the message.  One example is that I
> >believe that the destination URL is changed by the proxy and therefore
> >cannot be part of the signed message
> 
> predictable by the end-points, then it is possible to define an invariant which is
> signed by the sending endpoint and verified by the receiving endpoint. This
> applies for example to destination URI (See integrity protection of CoAP Option
> “Proxy-Uri" in Appendix A of draft-selander-ace-object-security).
> 
> invariant and the corresponding data cannot be integrity protected endpoint-to-
> endpoint.

Again - good points to be covered in the draft if it is going to be talking about CoAP as a message format.  Otherwise generic information is sufficient.  Is CoAP the "only" format that is proposed for the constrained layer?

> >>requirement  is to make sure that the new terms avoids this confusion
> >>by decoupling ACE  terminology from CoAP/REST terminology, e.g. using
> >>Consumer/Provider  instead of Client/Server. But I’m not sure it is
> >>worth the effort. The current  terminology (except for CAS) at least
> >>has the good that it is known to a much  larger community.
> >>
> >> Göran
> >
> >

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 13 Aug 2015 10:47:43 +0200

On 2015-08-13 08:34, Jim Schaad wrote:

> One chooses a terminology and sticks to it.

I don't think Göran was disagreeing with that (neither do I).
I the chosen terminology is (as stated in the actors draft):

C, RS, AS, RO (coming from OAuth)
CAS, RqP (invented here to represent the new actors on the Client side).

We should re-check the document to see if we are using the terms Client 
or Server in the CoAP sense somewhere, although I doubt it.

> If they are to be considered part of the standard architecture draft,
 > the absolutely need to be defined here and not in some other place.
 > I am not seeing a draft which is jumping out as the pub-Sub draft.
 > But it should probably just be defining protocols and not
 > architecture. This would be true of other drafts as well.
 >  They can restate a small piece of an architecture, but I expect this 
draft to
 > cover all of the core/normal items that are going to show up in an 
architecture.
 >  If I have to read 15 drafts to understand the architecture, I will 
never be able
 > to do an adequate job of evaluating the security properties and if 
the solutions
 > are going to actually solve the problem.

The publish subscribe draft Göran refers to is 
draft-koster-core-coap-pubsub-02, however this draft does only describes 
the CoAP part of it and does not go into the details of the ACE problem 
space.
If we want to define a new actors to represent this, it would be the 
"Untrusted Intermediary". Question is, what is the value to specify it 
as an actor in this draft, since we cannot require or expect any 
specific behavior from it and thus we cannot assign (security) tasks to it.

[...]
> Again - good points to be covered in the draft if it is going to be talking about
 > CoAP as a message format.  Otherwise generic information is
 > sufficient.
> Is CoAP the "only" format that is proposed for the constrained layer?
>

I think at the level of the usecases and the actors draft we don't want 
to be specific to CoAP. The CoAP specific handling of proxies et al. and 
the resulting security implications should be dealt with in the solution 
documents.
Do you think the generic information on proxies given in the actors 
draft at this point is sufficient?

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 13 Aug 2015 10:34:39 -0700

> From: Ace [mailto:[email-masked]] On Behalf Of Ludwig Seitz
> Sent: Thursday, August 13, 2015 1:48 AM
> To: [email-masked]
> >> Yes, the ACE entities and resources are the same.  But the CoAP
> >> entities and resources may be different. For example, the Resource
> >> Server may be a CoAP Client, and a Message/Pub-Sub Broker may be a
> >> CoAP Server.  The point I was trying to make was just that for
> >> example the term “Client” may be ambiguous unless it is understood
> >> whether it is the ACE entity or the CoAP entity that is being referred to.
> >>
> >
> We should re-check the document to see if we are using the terms Client or
> Server in the CoAP sense somewhere, although I doubt it.
> 
> >>>
> >> Various proxies are presented in the CoAP specification and the
> >> Pub-Sub Broker in a separate draft. Some of these are mentioned in
> >> section 3.1 but maybe this needs further elaboration?
> >
>  > But it should probably just be defining protocols and not  > architecture. This
> would be true of other drafts as well.
>  >  They can restate a small piece of an architecture, but I expect this draft to  >
> cover all of the core/normal items that are going to show up in an architecture.
>  >  If I have to read 15 drafts to understand the architecture, I will never be able
> > to do an adequate job of evaluating the security properties and if the solutions
> The publish subscribe draft Göran refers to is draft-koster-core-coap-pubsub-02,
> however this draft does only describes the CoAP part of it and does not go into
> the details of the ACE problem space.
> If we want to define a new actors to represent this, it would be the "Untrusted
> Intermediary". Question is, what is the value to specify it as an actor in this
> draft, since we cannot require or expect any specific behavior from it and thus
> we cannot assign (security) tasks to it.

Ok - so from a architecture point of view we have
* An actor who will keep data at rest (affect security as session based connections are not sufficient)
* A solution to the fact that either C or RS may not always be active, but still want to publish/get data

These seem to me to be good reasons to document them

Göran in a message said that these data stores might be performing security operations - i.e. checking that the message is coming from the right entity - that means it needs to be incorporated into the security solution somehow.

>From a security point of view, how are these entities discovered and how does one know if they can be used or if a different entity should be used?  The last thing one wants to do is to subscribe to A when one should have subscribed to B in order to get information about R.

It is not clear that a data store is always going to be untrusted  It might in fact be a trusted agent.  In some cases it might, for example, upgrade the encryption security on a message because it is going to forward that message over the internet rather than a local net.  

> >> CoAP Options “Observe" or "Max-Age", then it is not possible to
> >> define an invariant and the corresponding data cannot be integrity
> >> protected endpoint-to- endpoint.
> >
>  > CoAP as a message format.  Otherwise generic information is  > sufficient.
> I think at the level of the usecases and the actors draft we don't want to be
> specific to CoAP. The CoAP specific handling of proxies et al. and the resulting
> security implications should be dealt with in the solution documents.
> Do you think the generic information on proxies given in the actors draft at this
> point is sufficient?

As I said above, yes that is sufficient as long as generic expected behaviors are covered.
By the way, I think that proxies are even more likely than data stores to be untrusted agents.

Jim