Subject: Re: [Ace] U1.2 in Use Case Document

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 04 Mar 2015 09:39:08 +0100

Hi Eve,

Am 04.03.2015 04:25 schrieb Eve Maler <[email-masked]>:
>
> It seems to me that Eve (ahem), as the owner of the client, is just seeking access to a resource that Alice or Bob controls access to but can't be described as an owner of anything else. There are indeed, however, several "subjects" in this picture, that is, several identities worth tracking and authenticating. 
>
> There is an inherent (and valuable for ACE purposes) asymmetry in the relationship between those who are in a position to grant access and those who seek it. If the tables are turned for some other resource, with Eve in the resource owner role and Alice in the client owner role, that doesn't make it a two-way relationship -- it's still two one-way relationships.

If two parties are communicating with each other, each of these parties may have its own security policies. If Eve is the client owner, she will want to control which data is entering and leaving her device. She doesn't want her client to accept data from untrusted sources and she doesn't want her device to send data to untrusted devices. In scenarios where she is present at the time of access, she can authorize that her device accesses a resource by pressing a button or something like that. In scenarios where she is absent (we have a couple of use cases with absent owners) she needs other means to keep control over her device. If the device is not able to determine if Eve authorized the access to a certain resource, it is not able to enforce Eve's security policies. If Eve's device communicates with unauthorized devices, the integrity and confidentiality of her data will likely be compromised.

>
> FWIW, here is the terminology used in UMA on the technical and contractual levels for all these concepts: 
>
> Technical             Contractual 
>
> --                    Individual (human) 
> --                    Non-Person Entity ("legal person" like a company) 
> --                    Subject (can be an individual or an NPE) 
>                       (all of the rest are a kind of Subject...) 
> resource owner        Authorizing Party 
> authorization server  Authorization Server Operator 
> resource server       Resource Server Operator 
> client                Client Operator (e.g. Google, running Google Apps) 
> requesting party      Requesting Party 
> --                    Requesting Party Agent (e.g. an employee of a corporate RqP) 
>
> The kind of Principal meant in the use case doc, I would argue, is exclusively the resource owner kind of principal. If you want to go back and see definitions, UMA gets its definition of resource owner from OAuth, which defines it as "An entity capable of granting access to a protected resource." The client, on the other hand, is about "making protected resource requests with the resource owner's authorization and on the requesting party's behalf." This makes the asymmetry clear.

If you define the resource owner as the authorizing party then clearly the resource owner authorizes. In this case both Alice and Eve are resource owners since both are authorizing. Alice is authorizing who accesses her door lock and Eve authorizes her client to access the door lock by pushing a button.

For scenarios with an active user that can authorize by pressing buttons we can decide to not consider that Eve authorizes her device. But for constrained devices that might not have means for user interaction (e.g., don't have a display or a button), and for scenarios where we don't have an active user for other reasons, we need more sophisticated authorization.

Best regards
Steffi

>
> Eve 
>
> > On 3 Mar 2015, at 5:06 AM, Hannes Tschofenig <[email-masked]> wrote: 
> > 
> > Hi all, 
> > 
> > let me try to see whether I understand the issue that's currently under 
> > discussion. 
> > 
> > It seems that the debate focuses on this requirement from the 'Container 
> > monitoring' use case: 
> > 
> > " 
> >   o  U1.2 Principals want to grant different access rights for 
> >      different resources on an endpoint. 
> > " 
> > 
> > The question that surfaced here is whether 'principal' is the right term 
> > or not. The document defines principal as "A subject who is either a 
> > resource owner or a client owner or both." 
> > 
> > Here is a slightly modified example using a door lock scenario that may 
> > help us see through this case. Imagine a family with a kid: Alice, Bob 
> > and their young child Eve. 
> > 
> > Alice and Bob bought one of these Internet connected door locks and now 
> > want to configure it. They want to configure it in such a way that all 
> > three can enter their house just using their smart phone (and a 
> > specially loaded app). 
> > 
> > Whether the authorization server is included in the door lock itself or 
> > is part of some other home appliance does not really matter for the 
> > moment. In any case, Alice and Bob configure the door lock in such a way 
> > that Eve is granted access. Alice and Bob are the owner of the resource 
> > (=door lock) but even if they do not 'own' the door lock (but have 
> > rather rented it) does not really matter. 
> > 
> > The authorization server does not necessarily need to know that this 
> > access control policy is about "Eve". All it cares is that there is an 
> > entry in the access control list that points to some credential on some 
> > device. That credential happens to point to app on the smart phone Eve 
> > is using. 
> > 
> > Now, the question is how Eve, who is the client owner, fits into that 
> > picture. She would use her phone (=client) to request access to the door 
> > but she would not be involved in provisioning the access control policy 
> > at the authorization server. 
> > 
> > Did I correctly understood this issue? 
> > 
> > Ciao 
> > Hannes 
> > 
> > _______________________________________________ 
> > Ace mailing list 
> > [email-masked] 
> > https://www.ietf.org/mailman/listinfo/ace 
>
>
> Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl 
>
> _______________________________________________ 
> Ace mailing list 
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ace 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 04 Mar 2015 09:56:35 +0100

Hi Steffi,

only a quick comment on this selective issue (still working my way
through the other issues).

> If two parties are communicating with each other, each of these
> parties may have its own security policies. If Eve is the client
> owner, she will want to control which data is entering and leaving
> her device. She doesn't want her client to accept data from untrusted
> sources and she doesn't want her device to send data to untrusted
> devices. In scenarios where she is present at the time of access, she
> can authorize that her device accesses a resource by pressing a
> button or something like that. In scenarios where she is absent (we
> have a couple of use cases with absent owners) she needs other means
> to keep control over her device. If the device is not able to
> determine if Eve authorized the access to a certain resource, it is
> not able to enforce Eve's security policies. If Eve's device
> communicates with unauthorized devices, the integrity and
> confidentiality of her data will likely be compromised.

Looking at the way how (since applicable to this scenario) smart phones
work today there would be another (independent) authorization check at
the time Eve installs the app on her phone. It might asks for
permissions to access the Bluetooth smart stack and maybe for some other
privileges that have to do with the interaction of the app and the
authorization server (since the client app will have to authenticate to
the authorization server and might even use an existing identity
management service for it).

Of course, Eve will have to trust the app developer to a certain extend
and will have to carefully evaluate the permissions it is asking for.

Is this what you have in mind with 'client owners wanting to grant
different access rights for different resources?"?

Ciao
Hannes

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 04 Mar 2015 10:32:29 +0100

Hi Hannes,

> different access rights for different resources?"?

I am not that interested in smartphone security and I don't think we 
should work on the security of smartphone apps in ACE. What I am 
interested in is to find out what we need to do to enable Eve's device 
to act in Eve's behalf if Eve is not able to instruct the device at the 
time of access.

A temperature sensor on a banana box in the container scenario should be 
able to decide if it can send its temperature values to a certain 
cooling unit or not. It should not send its temperature values to the 
transloading company. However, it can give the transloading company 
information about its owner (the fruit vendor) so that the transloading 
company knows how to handle the banana boxes.

In the smartphone case, Eve could configure in the app which resources 
her device is allowed to access on its own (my phone may open door-locks 
that belong to Alice and look out for new music on devices that belong 
to Eric and give my training plan to my cross trainer. all other actions 
are not allowed).

We don't need explicit authorization (configuration of a fine-grained 
access control) for every use case. For some use cases, it may suffice 
to authorize a device because it can be authenticated. But in other 
cases, it will be necessary to define exactly what my device is allowed 
to access to ensure the integrity and confidentiality of my data.

Best regards,
Steffi

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 04 Mar 2015 15:37:46 +0100

Hi Steffi,

some remarks below.

On 03/04/2015 10:32 AM, Stefanie Gerdes wrote:
> should work on the security of smartphone apps in ACE.

The smartphone app was just the continuation of the use case to make the
discussion less abstract.

> What I am
I believe this sentence means a "yes" to my question.

> company knows how to handle the banana boxes.

Most likely it would be the other way around: there would be an access
control policy configured at an authorization server that allows
selected parties access to the sensor readings (in our case the cooling
unit would be allowed to access those sensor readings). The sensor is
the resource server in our terminology and the cooling unit would be the
client.

The firmware on the cooling device would tell it whether it should talk
to temperature sensors (rather than heart-rate monitors, for example).
Most likely there is a pre-configuration step happening prior to the
usage where the cooling unit is configured to only talk to the sensors
in the same container rather than (maybe accidentally) to temperature
sensors from other contains. Whether this information needs to 'entered'
into an authorization server and then pushed to the devices, as the OMA
LWM2M guys do it, or rather pulled (as OAuth would do it) is something I
don't have a strong opinion about.

> to Eric and give my training plan to my cross trainer. all other actions
If the app supports more than one functionality then the app may also
ask for various permissions.

> to access to ensure the integrity and confidentiality of my data.

I agree. The actual policy is something that will depend on a variety of
factors, such as use case, application functionality, operating system
capabilities, etc.

Ciao
Hannes

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 04 Mar 2015 16:11:54 +0100

Hi Hannes,

> the resource server in our terminology and the cooling unit would be the

Just to get this straight: From your point of view, the authorization 
server is controlled by the fruit vendor who can configure access 
permissions for the temperature sensor. The temperature sensor is the 
resource server. Right? I wonder why you chose this setting? How do you 
determine if a device is a resource server or a client?

> don't have a strong opinion about.

Yes, you can configure the authorization policies for the cooling unit 
manually in a pre-configuration step. That would be one solution to 
solve the authorization problem on the client side.

A more sophisticated authorization mechanism would also allow to 
dynamically update authorizations. This would make it possible to define 
that only devices of a certain fruit vendor are authorized. It will 
likely be difficult to determine if a sensor is in the same container or 
not.

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: Hannes Tschofenig <[email-masked]>
Date: Wed, 04 Mar 2015 16:24:04 +0100

Hi Steffi,

> determine if a device is a resource server or a client?

I assume that the authorization server for the temperature sensors and
the cooling unit is managed / controlled by the fruit vendor. The fruit
vendor has, after all, rented the container to deliver the fruits.

I determined the client vs. server depending on who initiates the
communication.

In either case, the sensor either needs to be configured with the
address of the cooling unit to send the data to or the cooling unit
queries the sensors for the current temperature and therefore needs to
know what the relevant sensors in the container are.

Do we want to standardize this type of configuration mechanism? I don't
know.

Ciao
Hannes