Subject: [Ace] Fwd: I-D Action: draft-ietf-ace-usecases-02.txt

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 05 Feb 2015 11:12:06 +0100

Hi all,

We submitted a new version of the use cases draft. Most changes are 
terminology changes: Instead of "Device Owner", the document now uses 
"Client Owner" or "Principal". Where applicable, "device" was replaced 
by "endpoint" accordingly. In 3.2 the phrasing of first item was changed 
according to the discussion on the list.

Best regards,
Steffi

-------- Forwarded Message --------
Subject: I-D Action: draft-ietf-ace-usecases-02.txt
Date: Thu, 05 Feb 2015 01:58:41 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
  This draft is a work item of the Authentication and Authorization for 
Constrained Environments Working Group of the IETF.

         Title           : ACE use cases
         Authors         : Ludwig Seitz
                           Stefanie Gerdes
                           Goeran Selander
                           Mehdi Mani
                           Sandeep S. Kumar
	Filename        : draft-ietf-ace-usecases-02.txt
	Pages           : 24
	Date            : 2015-02-05

Abstract:
    Constrained devices are nodes with limited processing power, storage
    space and transmission capacities.  These devices in many cases do
    not provide user interfaces and are often intended to interact
    without human intervention.

    This document comprises a collection of representative use cases for
    the application of authentication and authorization in constrained
    environments.  These use cases aim at identifying authorization
    problems that arise during the lifecylce of a constrained device and
    are intended to provide a guideline for developing a comprehensive
    authentication and access control solution for this class of
    scenarios.

    Where specific details are relevant, it is assumed that the devices
    use the Constrained Application Protocol (CoAP) as communication
    protocol, however most conclusions apply generally.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ace-usecases-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ace-usecases-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: [email-masked]
Date: Thu, 05 Feb 2015 01:58:41 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Authentication and Authorization for Constrained Environments Working Group of the IETF.

        Title           : ACE use cases
        Authors         : Ludwig Seitz
                          Stefanie Gerdes
                          Goeran Selander
                          Mehdi Mani
                          Sandeep S. Kumar

Abstract:

---

From: Göran Selander <[email-masked]>
Date: Fri, 6 Feb 2015 10:44:57 +0000

Hi Steffi,

Some comments on the new proposed terminology. First of all, removing
ownership from the description of the terminology is a definite
improvement! But I still have a problem with this version, let me include
your terminology (Section 1.1.) for the convenience of the readers:

"Resource:  An item of interest.

Resource Server:  The endpoint which hosts resources the Client wants to
access.  Resource Servers might be located on constrained devices.

Client:  An endpoint which wants to access a resource on the Resource
Server.  This could also be located on a constrained device.

Resource Owner:  The subject who controls the access permissions of a
resource.

Client Owner:   The subject who controls the access permissions of a
client.

Principal:  A subject who is either a resource owner or a client owner or
both."

On the Resource Owner side it is very clear what is the item of interest,
where it is hosted, who wants to access it and who decides about the
permissions to access it:

- What: The Resource
- Where: At the Resource Server
- Who wants to access: The Client
- Who decides about who has the right to access: The Resource Owner

With regards to the Client Owner controlling the “access permissions of a
client", that is not at all clear to me. What is being accessed at the
client? Who wants to access?

Regarding Section 2.1:

"There are various reasons for assigning a function (client or server) to
a device, e.g. which device initiates the conversation, how do devices
find each other, etc.  The definition of the function of a device in a
certain use case is not in scope of this document. Readers should be aware
that there might be reasons for each setting and that endpoints might even
have different functions at different times."

I remember you have used this reasoning to argue that it is not possible
to express what is the Resource in a given use case. If this is the case,
that with this terminology it is not possible to specify what are the
"items of interest" in a given use case, then I think the terminology is
not satisfactory. The purpose of the use case document is to highlight
what is the problem we should solve. If we can’t use the term “Resource”,
then what need do we have for “Resource Server” and “Resource Owner”?
Furthermore “Client” is defined as the Resource accessing endpoint, so
then neither that nor "Client Owner” is well defined.

The only remaining term is “Principal”, which then becomes a synonym to
“someone setting access control policies”. If this is the only thing you
want to express, then I think you should remove the rest of the terms, as
they are not used. (Resource Server or Client can be replaced by “some
potentially constrained device” etc.) But I think this is not at all
clarifying what are the authorization problems. In particular since I have
hard time understanding what exactly are the access control problems on
the client side, I think it would be more helpful to explain that in a
given use case. What are the access control policy considerations of the
fruit vendor, the transloading personnel and the container owners?

And then maybe we can avoid the exercise of first defining terms in
section 1.1 and then disqualifying the use of all terms except one in
section 2.1?

Best Regards
Göran

On 2015-02-05 11:12, "Stefanie Gerdes" <[email-masked]> wrote:

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

---

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 09 Feb 2015 16:22:45 +0100

Hi Göran,

> client? Who wants to access?

In the scenario we are analysing, there is the client on one end of the 
conversation and the Resource Server on the other side. The client may 
have a different owner that the Resource Server. On the Resource Server 
side, Resource Owners may want to control which data is entering and 
leaving their resources. On the client side, Client Owners may want to 
control which data is entering and leaving their endpoints.

To put it another way: The Client Owner may want to make sure that only 
authorized endpoints can send data to the client and that the client 
sends data only to authorized resource servers. Just as on the Resource 
Server side, the Resource Owner may want to make sure that only 
authorized endpoints can send data to the Resource Server and the 
Resource Server sends data only to authorized clients.

We could change the definition of Client Owner from "The subject who 
controls the access permissions of a client." to "The subject who 
defines authorization policies for a client". Does that solve your problem?

> then neither that nor "Client Owner” is well defined.

I don't think I understand your reasoning. I can't remember saying that 
we don't know what the resource is in a given use case.

The paragraph from section 2.1 just states that it is not clear whether 
an endpoint in a use case is a CoAP client or a server. I don't think 
that it is even necessary to be able to assign a function since I didn't 
see any evidence yet that this would be useful.

As I mentioned in my last e-mail to Ludwig, we need the terms "client 
and server (or resource server) to express the problem that needs to be 
solved, e.g. U5.7" (cf 
http://www.ietf.org/mail-archive/web/ace/current/msg00973.html).

We can change "Resource Server" to "server" to fit it to the CoAP 
terminology. If we don't need the terms Client Owner and Resource Owner, 
we can remove these terms from the terminology section. Is that what you 
are proposing?

> fruit vendor, the transloading personnel and the container owners?

We can play out Ludwig's proposal and use the names of the specific 
actors in the problem summary section. Ist that what you are proposing?

For the container monitoring use case, the section would look like this:

U1.1 Principals such as the fruit vendor, the transloading personnel or 
the container owners want to define authorizations for their resources 
and endpoints.

U1.2 The fruit vendor requires the integrity of the sensor data that 
pertains the state of the goods for climate control and to ensure the 
quality of the monitored recordings.

U1.3 The container owner requires the integrity of the sensor data that 
is used for climate control.

U1.4 The fruit vendor requires the confidentiality of the sensor data 
that pertains the state of the goods.

U1.5 The fruit vendor may have several types of data that may be 
controlled by the same endpoint, e.g., sensor data and the data used for 
logistics.

U1.6 The fruit vendor requires the confidentiality of the data that is 
used to locate the goods.

U1.7 The fruit vendor requires the integrity of the data that is used to 
locate the goods.

U1.8 The transloading personnel requires the integrity of the data that 
is used to locate the goods.

U1.9 The container owner and the fruit vendor may not be present at the 
time of access and cannot manually intervene in the authorization process.

U1.10 The principals want to grant temporary access permissions to a party.

U1.11 Messages between client and resource server might need to be 
forwarded over multiple hops.

U1.12 The constrained devices might not always be able to reach the 
Internet.

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Tue, 10 Feb 2015 08:19:42 +0000

Hi Steffi,

Thanks for your constructive answer. A concrete request below.

>control which data is entering and leaving their endpoints.

I think it would be very helpful if you explain what this means in terms
of the use cases, see below.

>we don't know what the resource is in a given use case.

Maybe I misunderstood. Well then, let’s use it. See below.

>the container owners want to define authorizations for their resources

Could we replace this requirement with something concrete? As it is stated
now I interpret it roughly as “everybody wants to set access policies for
their things”.

Could we then use the proposed terminology to express:
- What are the Resources.
- Which are the Clients accessing the Resources.
- What are the access policy considerations of the Resource Owners. I.e.:
What Clients should have access to what Resources.
- What are the access policy considerations of the Client Owners.

Thanks
Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 11 Feb 2015 17:17:27 +0100

Hi Göran,

I don't see how your questions provide anything useful to the use cases.

The use cases document is about the problems that need to be solved. So 
the question is if there are relevant problems missing from the use 
cases or if there is something wrong with the described problems.

You seem to believe that we failed to list authorization problems 
because the terminology is not suitable to describe them. Please provide 
text that describes these problems.

If you think that the description of a problem is wrong, please provide 
details why they are wrong and provide text which you think will help to 
describe the problem correctly.

Currently, it sounds like you don't like the terminology in the use 
cases draft because certain solutions use a different terminology. It is 
not the purpose of the use cases draft to define terminology for the 
authorization solution ACE will choose.

If there is nothing wrong with the problems described in the use cases 
and no relevant problems are missing from the descriptions, I see no 
need to change the terminology.

Best regards,
Steffi

-- 
Stefanie Gerdes			Tel: +49 421 218 63906
TZI Universität Bremen		E-Mail: [email-masked]
Bibliothekstr. 1, MZH 5150
28359 Bremen, Germany

---

From: Göran Selander <[email-masked]>
Date: Wed, 11 Feb 2015 17:45:51 +0000

Hi Steffi,

I asked you to describe, using your proposed terminology, what are the
authorization problems on the Client side in this concrete use case,
because I don’t understand exactly what these problems are.  I may be
wrong, but one interpretation of your answer is that it is not possible to
express the authorization problems on the Client side with this
terminology.  Or alternatively that there are no relevant authorization
problems on the Client side.  Or maybe you just didn’t see the point of
the exercise? 

If we don't explain what are the relevant authorization problems on the
Client side in this use case, then I disagree with the term “Principal” in
U1.1. 

Proposal:

1. replace the term “Principal" by “Resource Owner”, and change the list
of actors accordingly,

or alternatively:

2. replace U1.1 with more concrete statements such as "The fruit vendor
defines the access control policies for the sensor data that pertains the
state of the goods”, etc.

Best regards,
Göran

On 2015-02-11 17:17, "Stefanie Gerdes" <[email-masked]> wrote:

>>>> With regards to the Client Owner controlling the “access permissions
>>>>of
>>>> a

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 12 Feb 2015 15:17:37 +0100

Hi Göran,

I don't see the point of this exercise. I explained the authorization 
problems several times already, e.g., two times in my last E-Mail. You 
even admitted that there are problems on both sides. I think your 
solution is to apply the same solution twice (see 
http://www.ietf.org/mail-archive/web/ace/current/msg00967.html). 
Therefore, I don't understand why you insist that we should not describe 
these problems in the use cases draft.

Protecting resources on the on the resource server side is only one 
possibility for authorization and may not solve every problem. It is not 
a good idea to design the problem descriptions in the use cases draft to 
fit to a specific solution because that blindfolds us for other 
solutions that might be more suitable.

To describe the authorization problem yet again:
In the container monitoring case, the fruit vendor wants to define 
authorization policies for the temperatur sensors and the container 
owner wants to define authorization policies for the ventilation system. 
One of their devices may be a client, one of them may be a resource 
server. If the ventilation system is the client, the container owner 
will only want to allow data from authorized sources. If the temperature 
sensor is the client, the fruit vendor will only want to send sensor 
data to authorized resources.

Principals can also be Resource Owners so I don't see the point in 
discussing this over and over.

We could change: "Principals such as the fruit vendor, the transloading 
personnel or the container owners want to define authorizations for 
their resources and endpoints."
to
"Principals such as the fruit vendor, the transloading personnel or the 
container owners want to define authorizations for their resources 
and/or endpoints." if that helps things.

Best regards,
Steffi

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 12 Feb 2015 15:51:03 +0100

> these problems in the use cases draft.

Perhaps the reason is that your explanation was not quite convincing.

As far as I see it there are indeed _security_ problems both on the 
client and the server side. But you have failed to convince me that 
there is an _authorization_ problem on the client side.

> authorization policies for the temperature sensors and the container
> will only want to allow data from authorized sources.

I see this as "the container owner will only want to receive or send 
data from/to authenticated sources". It is after all the client which 
took the initiative to request or send data (otherwise it would be a 
server in that specific message exchange).

Perhaps you mean that there should be policies that determine which 
(authenticated) servers a device can contact when acting in a client 
role?  I think that calling these authorization policies would be a 
misnomer, since there is no enforcement. Either the code on the device 
takes these policies into consideration before sending a request or not.
I would call this type of policies 'security policies'.

> If the temperature

In my mind that would be "send sensor data to authenticated servers".

> discussing this over and over.

The point is that the term "Principal" makes the problem description 
vague and unclear, at least to me. I still don't see why we cannot reuse 
the terminology of OAuth or UMA.

/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: Olaf Bergmann <[email-masked]>
Date: Thu, 12 Feb 2015 16:19:10 +0100

Hi Ludwig,

> takes these policies into consideration before sending a request or

This is already (implicit) authorization. But sometimes you might want
to differentiate the actions that a client does on authenticated
endpoints. For example, it might be allowed report certain sensitive
data it has collected to resource server A whereas it must not disclose
this data to other resource servers it also has communication
relationships to.

This decision is very common in desktop systems where a dialog box opens
saying "allow application x to send data to service y?". The issue with
M2M is that you do not have modal dialog boxes popping up and therefore
need to find other ways of performing this explicit authorization.

Grüße
Olaf

---

From: Göran Selander <[email-masked]>
Date: Fri, 13 Feb 2015 08:23:19 +0000

Hi Steffi,

Thanks for starting the exercise.  I’ll refrain from commenting
“blindfolds” (though it is tempting) and stick to the use case, inline.

>owner wants to define authorization policies for the ventilation system.

Well summarized, these are the relevant authorization problems. Replace
U1.1 with something like this and we are done with use case 1.

>server. 

Allow me to complete the exercise, using your proposed terminology. We
agreed a few mails ago that the resources are well defined
http://www.ietf.org/mail-archive/web/ace/current/msg00982.html

(Or you formulated it "I can't remember saying that we don't know what the
resource is in a given use case.”, which I hope means that you agree that
the resources are well defined.)

Access control problem 1: Entity 1 wants to access a temperature.

Clearly, the “item of interest”, which someone wants to access, is: the
temperature.

- Resource: Temperature
- Resource Server: Temperature sensor hosting device
- Resource Owner: Fruit vendor
- Client: Device hosting Entity 1

Access control problem 2: Entity 2 wants to access a ventilation actuation
resource (say a fan setting)

Clearly, the “item of interest”,  which someone wants to access, is: the
fan setting. 

- Resource: Fan setting
- Resource Server: Ventilation actuator hosting device
- Resource Owner: Container Owner
- Client: Entity 2

Of course an accessing entity (“client”) of one resource can be hosted in
the same device as some other resource. This doesn’t make one resource a
client of another resource. In summary, there are two distinct access
control problems, and there may be control logic wherein one resource
representation triggers an access request to another resource.

>If the ventilation system is the client, the container owner
>will only want to allow data from authorised sources.
>If the temperature sensor is the client, the fruit vendor will only want
>to send sensor

I take it you mean that the ventilation system hosts a client of the
temperature resource.

Now, what kind of access control problem is “only allow data from
authorized sources”? (Analogous comments for sending to authorized
resources.)

- The client should also "only allow access tokens from authorized
sources” (authorization servers).

- It should "only allow data from authorized cloud services" of the
container owner (not particular for this example, but just as an example
of another source of data that needs to be "authorized”).

- A device should "only allow data from authorized drivers" in
communicating with its resources.

- It should "only allow data from authorized ciphersuites" in
communication with the resource (if you view decryption as a source of
potentially unauthorized data).

If you think about it, there is a lot of things that needs to be
“authorized”.  All these "authorization problems” can potentially be hard
coded. All can potentially be addressed with access control policies,
decision, enforcement etc.. My objections to include this category of
problems in ACE is:

- The problem is not well scoped (as this list of examples tries to
illustrate) compared to the access control problems above
- I see no evidence in the use cases that this is an important problem
that needs to be addressed with access policies etc..
- This as an independent problem which makes the total problem statement
more complex. 

Hence it should be left out of scope.

The casual “Principals want ..” formulation in the requirements is hiding
the fact that it is a priori different problems on the client side and the
resource side. Therefore your proposed formulation prevents a discussion
of the scope of ACE, and in essence presents a conclusion that the client
and resource problems are obviously similar and equally relevant, which I
don’t see any proof of.

>discussing this over and over.

"Mammals can also be Elephants”. (You mean of course "Elephants are
Mammals”.) Don't you see the point in discussing the statement “Mammals
walk on four legs”?

Bottom line: My proposal in the previous mail.

Best Regards,
Göran

>>>>>> Resource Server:  The endpoint which hosts resources the Client
>>>>>>wants
>>>>>> to
>>>>>> Principal:  A subject who is either a resource owner or a client
>>>>>>owner
>>>>>> or
>>>>>> both."
>>>>>>
>>>>>>
>>>>>> "There are various reasons for assigning a function (client or
>>>>>>server)
>>>>>> to
>>>>>> that there might be reasons for each setting and that endpoints
>>>>>>might
>>>>>> even
>>>>>> "items of interest" in a given use case, then I think the
>>>>>>terminology
>>>>>> is
>>>>>> want to express, then I think you should remove the rest of the
>>>>>>terms,
>>>>>> as
>>>>>> clarifying what are the authorization problems. In particular since
>>>>>>I
>>>>>> have

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 13 Feb 2015 17:32:33 +0100

Hi Göran,

> - Client: Device hosting Entity 1

We have two authorization problems here. The owner of the Resource 
Server that hosts the temperature may want to control the access to the 
temperature resource. The owner of the client may want to control which 
resources of which resource server a client is authorized and therefore 
safe to access (BTW, I don't know if it is important here, but in CoAP 
the client is an endpoint, not a device. I would expect the Resource 
Server to be an endpoint, too). The client must be able to answer the 
following question: Is it in the interest of my owner if I send a 
request to this resource (e.g. a get request) and receive data from this 
resource (the response to a get request that contains the temperature 
values for which the container owner needs integrity protection).

The client owner may solve the authorization problem by using implicit 
authorization: If the Resource Server can be authenticated, it is 
authorized. Client Owners may also decide that they want more 
fine-grained authorization.

For less-constrained devices that have a display and allow for user 
interaction, authorization can be achieved by user interaction at the 
time of access. In scenarios where devices communicate autonomously, the 
devices must be able to enforce the authorization policies of their 
owners themselves.

> - Resource Owner: Container Owner

The client owner may want to decide which resource server is an 
authorized source for the fan setting. The client must be able to answer 
the following question: Is it in the interest of my owner if I send a 
request to this resource (e.g. a put request with a confidential sensor 
value) and receive data from this resource (the response to this get 
request).

You missed to mention two other settings:

1. The temperature values are hosted by the Resource Server. The client 
is the fan. The client communicates directly with the Resource Server to 
obtain the temperature values that is than used to control the hardware 
of the fan. The Resource Owner, i.e., the fruit vendor, wants to make 
sure that sensor values are only accessed by authorized clients. The 
Client Owner, i.e., the container owner, wants to make sure that 
temperature values stem from authorized Resource Servers.

2. The fan settings are hosted by the Resource Server. The client is the 
temperature sensor. The client sends the temperature values directly to 
the Resource Server. The Resource Owner, i.e., the container owner, 
wants to make sure that the fan settings are only accessed by authorized 
clients. The Client Owner, i.e., the fruit vendor, wants to make sure 
that temperature values are only sent to authorized Resource Servers.

> representation triggers an access request to another resource.

I don't really understand what you are trying to express here. Do you 
want to state that a client can be located on the same device as a 
resource server? Do you want to state that one client can access several 
different resources?

I am glad that we agree that there are at least two authorization 
problems here. The disagreement thus seems to be about how these 
problems can be solved. You seem to be determined to solve this 
exclusively on the Resource Server side.

I don't think that the use cases document is the right place to discuss 
solutions. Your proposal to replace the more neutral term "Principal" by 
"Resource Owner" artifically restricts the solution space to the 
protection of resources which only considers the interests of one side 
of the conversation. I don't see a reason to restrict the solution space 
like this. If there is a way to solve the authorization problems on both 
sides of the conversation we should do so.

The use cases should reflect the main authorization problems in 
constrained environments. One characteristic of these environments is 
that devices often communicate autonomously. This is different from the 
typical web scenario where authorization can be achieved by user 
interaction. If we fail to address the main differences between web 
scenarios and constrained scenarios the use cases document would not be 
very useful.

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Mon, 16 Feb 2015 08:27:03 +0000

Hi Steffi,

Thanks for continuing the exercise. We disagree on small things and big
things. The small things we could probably sort out, but that won't anyway
have an impact on the use case draft. The big things we disagree about
will maybe not be resolved in this mail thread. Like, for example, the
arguments I gave in my previous mail (which you didn’t comment on) why the
client "authorization problem" as you have defined is an arbitrary choice
out of a set of client owner problems, which IMHO should be separated out
from this problem statement.

But, as this exercise shows, we also agree on big things, like access
control to resources. If I were editor of this document and listened to
this discussion, I would try to replace the only requirement formulation
we disagree about in the modified set:

"U1.1 Principals such as the fruit vendor, the transloading personnel or
the container owners want to define authorizations for their resources and
endpoints."

with two new requirements: one requirement about access control to
resources which we could agree about, and another requirement about client
owner concerns which we will maybe not agree about, and thus make an
“Editors note" that this requirement is not agreed to be in scope. For
example:

"U1.1a Resource Owners, such as the fruit vendor and container owner
requires to define access control policies for their resources such as
goods sensors and ventilation actuators, respectively.

U1.1b Client Owners, such as transloading personnel . . .
Ed. Note: . . . "

And then analogously for the requirements in other use cases.

I think this would be most honest to the reviewers of this draft, who
might otherwise believe that the current state of the draft is the agreed
position.

Best Regards,
Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 16 Feb 2015 19:03:01 +0100

Hi Göran,

> from this problem statement.

I thought that my explanation made pretty clear why this is not an 
arbitrary authorization problem. But I can try to make this even 
clearer. The charter says:

"This working group therefore aims to produce a standardized solution 
for authentication and authorization to enable authorized access (Get, 
Put, Post, Delete) to resources identified by a URI and hosted on a 
resource server in constrained environments. As a starting point, the 
working group will assume that access to resources at a resource server 
by a client device takes place using CoAP and is protected by DTLS. Both
resource server and client may be constrained."

Authorized access to a resource is not only a Resource Owner problem, 
but also a Client Owner problem. Since both the Client Owner and the 
Resource Owner may want to control access to resources (see also my last 
e-mail: http://www.ietf.org/mail-archive/web/ace/current/msg00990.html), 
the charter fits to the problems of both parties. A solution might 
decide to address these problems or not. But we cannot reasonably say 
that they are not there or that they are not in scope. In M2M scenarios 
it will be a security problem if a client is not able to decide if 
accessing a resource on a resource server is authorized by its owner. 
Therefore, we cannot omit this problem in the use cases document.

If you still think that the Client Owner problem is not in scope please 
explain to me why you think that it is not covered by the charter.

> we disagree about in the modified set:

Maybe this is part of the problem. The problems summary sections do not 
list requirements. They list problems.

We can split up the first problem into two problems:

U1.1: Resource Owners want to grant different access rights for their 
resources to different parties.
U1.2: Client Owners want to define for their clients if and how they are 
allowed to access resources hosted on a Resource Server.

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Mon, 16 Feb 2015 19:21:59 +0000

Hi Steffi,

About the Charter: If you ask about people what "authorized access to
resources identified by a URI and hosted on a
resource server” means, I think many would make the interpretation in U1.1
and very few, if any, would make the interpretation of U1.2. Stating that
the charter supports your claim is IMHO an over-interpretation.

There are also other "problems” of the Client Owners, like the examples I
mentioned in 
http://www.ietf.org/mail-archive/web/ace/current/msg00989.html. The
assumption that U1.2 should be solved with access control policies (if
that is implied) is arbitrary.

About requirement vs problem: If a candidate solution does not solve
problem U1.1 that is not acceptable. However, we should not discriminate
solutions which does not solve U1.2 with access control policies. If we
have this formulation, it should be made clear that U1.2 is optional.

You should keep "such as the fruit vendor and container owner” etc. in the
formulation, just as you had in your previous version. One major point
with the problem formulation is to explain the terminology in terms of the
actors of the use case.

Best Regards,
Göran

On 2015-02-16 19:03, "Stefanie Gerdes" <[email-masked]> wrote:

>>and

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 16 Feb 2015 21:29:15 +0100

Hi Göran,

please let me comment on your previous message as you keep referencing
this as a proof that client actions need not be authorized and hence
should be out of scope in your opinion.

> sources” (authorization servers).

Yes, that is very important once you try to define authorization
transfer to entirely cover a device's lifecycle. Meanwhile, many
solutions just use implicit authorization by accepting "access tokens"
only from authenticated authorization servers.

> of another source of data that needs to be "authorized”).

Sure, but this "cloud service" is just another resource server. Nothing
new here.

> communicating with its resources.

If "driver" here means "device driver" as in operating systems, then
this is clearly out of IETF scope.

> potentially unauthorized data).

Not sure what you mean here, but yes: You could distinguish your crypto
parameters according to the security objectives for a particular action. 
Given that this WG addresses the layer above DTLS, I do not think that
this is in scope of the ACE WG (while the CoAP interaction is).

> decision, enforcement etc.. My objections to include this category of

Sure, you can do without explicit authorization. Or with just addressing
half of the problem.

> illustrate) compared to the access control problems above

As you can see above, there is a very clear boundary of what falls in
scope and what does not.

> that needs to be addressed with access policies etc..

How about: "Transfer my credit card details only to resource x on device y"?
I really love today's web browsers that let me as a user take control
over which data is sent where. And I really want to be able to control
my M2M devices (sometimes called "smart objects") to also be that smart.

> - This as an independent problem which makes the total problem statement

As you can see, it does not make anything complex. It is just: The
resource owner wants to protect its resources, the client owner wants to
protect its client. No more, no less.

Grüße
Olaf

---

From: Göran Selander <[email-masked]>
Date: Tue, 17 Feb 2015 09:05:47 +0000

Hi Olaf,

>should be out of scope in your opinion.

Please note that I’m not questioning that all these actions, the ones you
list and the ones I list need to be carried out. I’m questioning that they
MUST be solved with access control policies. Recall the current
definition: "Client Owner:   The subject who controls the access
permissions of a client.”

I wanted to illustrate the issue by listing a number of other client
actions that you would typically not use access control policies for.

>only from authenticated authorization servers.

Exactly, and “implicit authorization” is a valid solution also to the
problem you list.

>Sure, but this "cloud service" is just another resource server. Nothing

This even further highlights the problem: the client accessing a cloud
service of the client owner is a completely client internal problem. Why
must all ACE solutions use access control policies for this?

>this is clearly out of IETF scope.

Agree, this was a bit of a stretch.

>this is in scope of the ACE WG (while the CoAP interaction is).

An illustration of a client concern which also could but probably should
not be handled with access control policies.

>Sure, you can do without explicit authorization. Or with just addressing

See below.

>my M2M devices (sometimes called "smart objects") to also be that smart.

I don’t really understand the use case where you need to transfer credit
card details to various devices. But if I would model that with access
control policies, I would consider the credit card details to be the
resource, and the device hosting a copy to be the client.

>protect its client. No more, no less.

The client concern is an independent problem, which we could leave to the
application developer to decide about. You state above that it is half of
the problem. Wouldn’t then the total problem statement be about twice as
easy if we remove the client concerns?

Best regards
Göran

---

From: Olaf Bergmann <[email-masked]>
Date: Tue, 17 Feb 2015 10:52:11 +0100

Hi Göran,

> actions that you would typically not use access control policies for.

Your point taken. But you are going into the solution space again (and I
agree that many of your proposed solutions are good practice and will
most likely do in many cases). But the goal of the use cases document is
to list authorization problems and their solutions. In my opinion it is
good to know the problem space and then design a solution for this. At
that step (and not before), it can be reasonable to decide that some of
the problems are addressed later or are addressed not at all by the
actual solution while some are a must. But to be able to deliberately
decide this, one must be aware of those problems. This, and not more, is
the intention of the use cases as I read it.

Grüße
Olaf

---

From: Göran Selander <[email-masked]>
Date: Tue, 17 Feb 2015 10:08:33 +0000

Hi Olaf

>the intention of the use cases as I read it.

We both seem to have issues with going into solution space. I think
everyone agrees that we intend to define an  solution to the access
control to resource problem which is based on access control policies set
by the Resource Owner. I’m happy with listing U1.2 as a client problem,
unless you insist that it must be solved by means of this machinery with
access control policies, decision, enforcement, etc.. Maybe we could just
replace the definition of the Client Owner with "The subject who decides
about a client.”?

---

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 17 Feb 2015 18:40:13 +0100

Hi Göran,

> have this formulation, it should be made clear that U1.2 is optional.

It is not optional to solve the U1.2 problem. In some cases 
authorization problems might be solved by implicit authorization. We can 
point this out in the security considerations. We can add the following 
to 3.2: Endpoints need to be enabled to enforce the authorization 
policies of their principals. In some cases, authorization problems 
might bei solved by implicit authorization (all authenticated entities 
are authorized).

> with the problem formulation is to explain the terminology in terms of the

We will not be able to decide whether a fruit vendor will in every case 
be a client owner or a resource owner. To make this more clear, we can 
add the following section to the container use case (I think this is a 
useful exercise since it shows the various possible settings):

# Variants

As mentioned in section 2, there are various reasons for assigning a 
function (CoAP client or server) to a device. This section lists 
possible settings for the communication between a temperature sensor and 
a fan actuator.

## Temperature Sensor and Fan Actuator Servers

Temperature sensors and fan actuators are servers, an aggregation server 
that belongs to the container owner is the client. Therefore, the fruit 
vendor is a Resource Owner. The container owner is a Resource Owner and 
a Client Owner.

Temperature sensors are resources on individual CoAP servers that belong 
to the fruit vendor. The CoAP client is an aggregation server that 
requests the temperature values from the servers and computes a 
temperature setting from these results. The result is then transmitted 
to the ventilation system of the container owner.

## Temperature Sensor and Fan Actuator Clients

Temperature sensors and fan actuators are located on clients. An 
aggregation server that belongs to the container owner is a server. The 
fruit vendor is a Client Owner. The container owner is a Client Owner 
and a Resource Owner.

The clients with the temperature sensors send a representation of the 
current temperature values to a resource on the aggregation server 
whenever the temperature changes. The client that controls the fan 
actuator requests the aggregated temperature values from the aggregation 
server. It uses observe to receive resource representations periodically.

## Temperature Sensor Client and Fan Actuator Server

Temperature sensors are located on a client. The fan actuator is located 
on a server. An aggregation server that belongs to the container owner 
acts as a resource server for the temperature sensor and as a client for 
the fan actuator server.

The client with the temperature sensor sends a representation of the 
current temperature values to a resource on the aggregation server 
whenever the temperature changes. The aggregation server then acts as a 
client to send the aggregated temperature values to a resource on the 
fan actuator server.

## Temperature Sensor Server and Fan Actuator Client Communicating directly

Temperature sensors are located on a server. The fan actuator is located 
on a client. The fruit vendor is a resource owner, the container owner 
is a client owner.

The client with the fan actuator requests the current sensor values 
directly from the nearest temperature sensor. It uses observe to get 
regular updates of the resource representation. The fan can react 
directly to local temperature changes and thus allows for an optimal 
temperature at different places within a container.

## Temperature Sensor Client and Fan Actuator Server Communicating directly

Temperature sensors are located on a client. The fan actuator is located 
on a server. The fruit vendor is a Client Owner, the container owner is 
a Resource Owner.

The client with the temperature sensor sends a representation of the 
current temperature values directly to a resource on the fan actuator 
server. The fan can react directly to local temperature changes as 
described above.

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Wed, 18 Feb 2015 08:17:43 +0000

Hi Steffi,

Your last mail make me hesitate whether we will progress beyond the first
use case before Dallas.

We’ve spent a good month discussing terminology and applying it to the
first use case. I initially challenged the terminology and whether the
term “Resource” (and thereby the other terms) is well defined. We agreed
that it is well defined and we made the exercise together on the first use
case. We disagree on U1.1 and replaced it with two problem statements,
here is your latest proposal

"We can split up the first problem into two problems:

U1.1: Resource Owners want to grant different access rights for their
resources to different parties.
U1.2: Client Owners want to define for their clients if and how they are
allowed to access resources hosted on a Resource Server."

Now you present a new section with implementation specific variants
including "aggregation servers” etc. which does not state what the
resources are. Obviously, one actor can be resource owner in one case and
client owner in another, but this doesn’t invalidate that the resources
are the temperature and the fan settings. Could we please note that, and
that and the resource owners are fruit vendor and container owner,
respectively? For example

U1.1: Resource Owners, such as fruit vendors and container owners, want to
grant different access rights to different parties for their respective
resources, such as temperatures and fan settings.

As a side note, I will be travelling next week with limited email access.
I would like to have a version of this draft that is representing the
views of the authors, or expresses the disagreements in the draft, before
the cutoff.

One comment inline.

Best Regards,
Göran

On 2015-02-17 18:40, "Stefanie Gerdes" <[email-masked]> wrote:

>It is not optional to solve the U1.2 problem.

Yes, we disagree about this. My view is that it must be optional to solve
the problem on the client side with access control policies. See recent
discussion with Olaf. As long as the “Client Owner” is defined in terms of
setting access rights, U1.2 is optional.

Please note the disagreement in the draft.

>In some cases 
>## Temperature Sensor and Fan Actuaor Servers
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 18 Feb 2015 09:26:14 +0100

> Your last mail make me hesitate whether we will progress beyond the first

Indeed, we are wasting a lot of time here.

I have only skimmed this discussion, but much of it seems to be
"requirements engineering" of the form that we need to avoid:
Each participant trying to change the requirements to suit their
favorite solution.

This is not only wrong, but also misguided: a use case document is not a
requirements document.

Can we now please finish the use cases?

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Feb 2015 10:11:32 +0100

Hi Carsten, Hi Steffi, Göran, Olaf,

I fear it is very difficult to describe scenarios in such a way that
they have nothing to-do with the solutions.

As such, it is quite natural that the different solution preferences
surface as one tries to provide more details and include requirements (*).

I would suggest to acknowledge the limitations of the use case approach
and let this issue rest for a little. During this time I hope we can
recruit a few other working group participants to review the use case
document and to share their views with us on the list. Maybe we get a
few additional perspectives on the topic.

Ciao
Hannes

(*): This use case document actually contains requirements. They are
labled as 'UX.X' and are contained in the 'Authorization Problems
Summary' sections.

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 18 Feb 2015 10:48:20 +0100

> Hi Carsten, Hi Steffi, Göran, Olaf,
...
> few additional perspectives on the topic.

Getting additional perspectives would indeed help resolving this situation.

/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: Göran Selander <[email-masked]>
Date: Wed, 18 Feb 2015 10:39:22 +0000

Hi Carsten, Hannes, Kepeng

I’m fine with letting this rest for a while, but as Carsten noted, the
current version of the draft is promoting the solution proposed by one of
the editors of the draft, and is not representing the views of all
authors. It would be good if the Dallas-version of the draft contained
some information making this clear, either in each section indicating
which terms and requirements are in discussion (as proposed in the
previous thread), or a separate section outlining the disagreement.

Best regards,
Göran

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Feb 2015 11:52:23 +0100

I am fully aware of this, Göran.

We just solicit more fedback from the rest of the group and then change
the text accordingly.

So, there will be a new version before the Dallas meeting submission
deadline.

Ciao
Hannes

---

From: Olaf Bergmann <[email-masked]>
Date: Wed, 18 Feb 2015 12:05:53 +0100

> I am fully aware of this, Göran.

I do not think so.

As Steffi with a patience of a saint tries to explain is that the
current text intentionally avoids any spin into a particular
direction. Removing the description of existing problems means promoting
a particular solution that ignores their existence.

As I said, there is always the option to deliberately (but not
accidently!) decided that a particular problem should not be reckoned in
a solution design.

Grüße
Olaf

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 18 Feb 2015 15:24:28 +0100

Hi Göran,

On 02/18/2015 09:17 AM, Göran Selander wrote:
> term “Resource” (and thereby the other terms) is well defined.

The term resource is defined in rfc2616 as "A network data object or 
service that can be identified by a URI". In CoAP, clients send requests 
"to request an action (using a Method Code) on a resource (identified by 
a URI) on a server." (RFC7252).

> We agreed
> are the temperature and the fan settings.

Temperature values and fan settings are resources on CoAP servers that 
can be accessed by clients. Clients can send data to these resources and 
receive data from resources. The resource itself is located on the server.

To define who the Client Owners are in a specific use case, we need to 
find out who the client and the server is in the use case. These are 
implementation specific, as you noted, which is why we state earlier in 
the document that the definition of the function of a device is not in 
scope of the document.

Since it seems to be very important to you do define who Resource Owners 
and Client Owners are, I made the exercise to analyze the possible 
settings. As you can see, there are various possibilities if the 
temperature sensor that belongs to the fruit vendor is a client or a 
server and if the fan actuator that belongs to the container owner is a 
client or a server. The variants section therefore demonstrates that it 
is not possible to define for the use case in general who the Client 
Owners are. I think these variants are helpful to understand the variety 
of settings better.

Defining who the Resource Owner is in a use case is even more difficult 
since the resource hosted on a server might not belong to the server 
owner (although the server owner is an indication). Therefore, every 
party that appears in the conversation can be a possible Resource Owner 
and there may be even more candidates in a real implementation. Defining 
them in a way that they fit to a specific solution is not a reasonable 
solution.

> Could we please note that, and

I don't see evidence for the fact that the fruit vendor and container 
owner are always Resource Owners.

> views of the authors, or expresses the disagreements in the draft, before

I think the disagreements are well presented on the mailing list. I 
don't think it is useful to put the discussion into the draft.

> Please note the disagreement in the draft.

U1.2 describes a problem. A problem cannot be optional. It is there or 
it is not there. Since we agree that U1.2 is a problem I don't know what 
the disagreement you mention is about.

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Wed, 18 Feb 2015 14:43:18 +0000

Hi Steffi,

I wait with replying to your comments, should they still be relevant,
until the review in a larger group.

Best regards,
Göran

On 2015-02-18 15:24, "Stefanie Gerdes" <[email-masked]> wrote:

>>>> There are also other "problems” of the Client Owners, like the
>>>>examples
>>>> I
>>>> mentioned in