Subject: [Ace] Security considerations of the use case draft

From: Göran Selander <[email-masked]>
Date: Wed, 14 Jan 2015 10:55:16 +0000

Hi Steffi,

Some further comments on section 3.

Section 3.2

"Configuration of Access Permissions"

"The access control policies set by the Principals need to be provisioned
to the device that enforces the authorization and applied to every
incoming request."

- These statements presuppose a specific solution - the provisioning of
access control policies. An alternative solution is that an authorization
decision is provisioned. Yet another solution is that client capabilities
are provisioned. Another solution is that neither of this information is
³configured/provisioned", but instead there is a request for an
authorization decision.

- "enforces the authorization" implies "applied to every incoming request²
so the latter is redundant.

"The device that makes the policy decisions should be able to evaluate
context-based permissions such as location or time of access"

"The device that makes the policy decisions should be able to take such
conditions into account."

- I agree that the resource server should be able to evaluate
context-based conditions but these statements are problematic. Assuming
the policy decision is separate in time and place from policy enforcement
and that the result of a decision is an access token contains the
information ³access granted during office hours". In this case, the time
and location of the access may not be known to the device that makes the
policy decision. 

Section 3.3

"It should be possible to update access control policies without manually
re-provisioning individual devices"

- This statement presupposes a particular solution, see above. (The
statement may actually be trivially true with solutions that does not
provision at all.)

Regards
Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 14 Jan 2015 15:26:37 +0100

Hi Göran,

Thank you for your comments.

> ³configured/provisioned", but instead there is a request for an

I think this is a misunderstanding. I think we agree that the principals 
are defining access control policies for their devices, right? They have 
some security objectives in mind that they want their devices to ensure. 
These policies somehow have to get to the device that enforces the 
authorization because this is the device that counts. And the device has 
to apply these policies to every request because otherwise the policies 
of the principal would not be ensured and the security of the system 
would be threatened.

You are right that there are a lot of different solutions to provide the 
policies to the device and it is not the intent of the paragraph to 
suggest a specific solution. Maybe rephrasing helps:

"The access control policies set by the Principals need to be provided 
to the device that enforces the authorization and applied to every 
incoming request."

What do you think?

> and location of the access may not be known to the device that makes the

Okay, how about: "If permissions require a certain context to apply at 
the time of access such as location or time, this context needs to be 
validated before the access is granted".

> statement may actually be trivially true with solutions that does not

As far as I remember this aims at the problem that it will often be 
impossible or at least very impractical to manually provision 
authorization information and/or keying material to the constrained 
devices for every change in the auhorization policies. Do you question 
that this is a problem or do you think that it is wrong to derive the 
above suggestion from the problem? Maybe it would help to rephrase it? 
Do you have a suggestion?

Thanks,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Thu, 15 Jan 2015 08:15:38 +0000

Hi Steffi,

Thanks for your reply. Comments inline.

On 2015-01-14 15:26, "Stefanie Gerdes" <[email-masked]> wrote:

>are defining access control policies for their devices, right?

Sorry for nitpicking, but let’s be careful with the words: You make the
distinction between “resource owner” and “device owner” and characterize
both as principals. In the case of principal = "resource owner” I think
the term “their devices” is not well defined.

>They have 

What I’m saying is that it is not necessarily access control policies that
are “provided to the device", so we should perhaps formulate it in a
different way? See below.

>Do you have a suggestion?

As a matter of fact I do: Use the terminology and formulations of section
4 of draft-seitz-ace-problem-description. The purpose of this text was to
come up with a formulation of the problem which is intended to be
solution-independent. It is by no means perfect and it may lack some
aspects related to recent changes of the use cases, but I haven’t heard
any serious issues (apart from the listed open issues). This may of course
be due to no one has read it, and then I think this is a good time to do
so :)

The point I was trying to make with the previous mail thread was that in
order to have an interesting discussion in the security considerations
section we need some basic terminology and assumptions, like there is in
the current version of the use case draft but less limited to specific
solutions. This does not necessarily imply that we should bring in a
detailed architecture or present different options of the architecture in
the use case document. An alternative is to move some of this content from
the use case document into a separate document, but as far as I understand
it is not the intention to have additional WG documents.

And I agree with your ambition in this mail: I do think we have a common
understanding of most things. It is "just" a matter of formulating them.
Allow me to come back with a proposal soon when I have more time.

Regards
Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 21 Jan 2015 12:40:14 +0100

Hi Göran,

> different way? See below.

How about:
The information that is needed to implement the access control policies
of the principal needs to be provided to the device that enforces the
authorization and applied to every incoming request.

If you don't agree with this phrasing, please provide text.

Thanks,
Steffi