Subject: [Ace] Security Domains

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 03 Jun 2014 12:37:55 +0200

Hi,

In my draft about actors in the ACE architecture [1] I explained that
the client (the one that wants to access a resource) and the resource
server (the one that hosts the resource) might belong to different
security domains. There is some discussion going on if this really is
the case.

I did not really get yet what the disagreement is about, so maybe
someone can help me with that.

I might be wrong, but I guess the fact that devices of different owners
might need to interact with each other is not really the question, is
it? The scenarios described in the use cases draft [2] indicate that
this is often the case. In the container scenario, the device of the
transport company will not belong to the supermarket chain. In the home
scenario, Jeffreys device for getting access to Janes house will belong
to Jeffrey and not to Jane. The device of the doctor which wants to
access data on Johns heart rate monitor will not belong to John. If it
is an emergency physician she might not even have seen John ever before.

So maybe there is some misunderstanding about security domains. My
intent for using this term was to emphasize the fact that C and RS do
not know each other at the time when C sends its first resource request.
This means, RS does not have any keys or other information about C and C
does not have any keys or other information about RS. Do we disagree
about this?

Thanks,
Steffi

[1] http://tools.ietf.org/pdf/draft-gerdes-ace-actors-00.pdf
[2] http://tools.ietf.org/id/draft-seitz-ace-usecases-00.txt

---

From: Rene Struik <[email-masked]>
Date: Tue, 03 Jun 2014 09:51:57 -0400

Hi Steffi:

I think authorization mechanisms should indeed facilitate deployment in 
heterogeneous trust domain settings, where the term "heterogeneous" 
applies across the entire device and system's life cycle.

BTW - I have not seen the "discussion going on" and "disagreement" 
regarding this topic on the ACE mailing list.

Rene

==

There is some discussion going on if this really is
the case.

On 6/3/2014 6:37 AM, Stefanie Gerdes wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 3 Jun 2014 16:15:55 +0200

> someone can help me with that.

Here in Stockholm there was a relatively extended discussion whether it is worth to separate the client owner and the resource owner function in the architecture and analogously separate out the Authorization Manager (less-constrained counterpart of the client) from the Authorization Server (less-constrained counterpart of the resource server).  

http://tools.ietf.org/html/draft-gerdes-ace-actors takes the view that this exercise is worthwhile.

Obviously, this is an architectural model and does not say anything how these functions are mapped to specific devices in a specific deployment.  If you don’t separate out the functions in the architecture, I believe the result will be single-owner thinking and it will be very hard to later address the multiple-owner aspect that is so central to the Internet of Things idea.  Others believe that initial deployments will all be single-owner and it will be hard to drum up input to an architecture enabled for multiple owners, but it will be relatively easy to extend the single-owner architecture later.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Jun 2014 11:00:36 -0400

> it? The scenarios described in the use cases draft [2] indicate that

I think that some people think that all cross-realm communication will occur
between brokers/proxies/"cloud services", vs occuring end to end.

I think your documents are pretty clear that e2e can be made to work.
Many people want to intermediate the relationship in order to charge a rent.

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

---

From: George Fletcher <[email-masked]>
Date: Wed, 04 Jun 2014 09:41:36 -0400

Just a quick comment. The OAuth2 flows started from a "single-owner" 
perspective and just doesn't cover a lot of use cases so the work by the 
User Managed Access (UMA) group in the Kantara Initiative is working to 
address access to resources by arbitrary (as yet not introduced) 
entities. Not exactly the same as the "multi-owner" problem but there 
are some similarities.

I'm in favor of supporting a multi-owner model.

Thanks,
George

---

From: Eve Maler <[email-masked]>
Date: Wed, 4 Jun 2014 06:59:24 -0700

If the two owners in question are, as described below, the resource owner and the client owner, this actually seems to align nicely with UMA's resource owner and requesting party (defined as "An end-user, or a corporation or other legal person, that uses the client to seek access to a protected resource. The requesting party may or may not be the same party as the resource owner."). A goodly part of the UMA architecture is dedicated to details necessary to separate these two entities.

http://tools.ietf.org/html/draft-hardjono-oauth-umacore-09

Eve Maler (sent from my iPad)
cell +1 425 345 6756
[email-masked]

> On Jun 4, 2014, at 6:41 AM, George Fletcher <[email-masked]> wrote:
> 
> Just a quick comment. The OAuth2 flows started from a "single-owner" perspective and just doesn't cover a lot of use cases so the work by the User Managed Access (UMA) group in the Kantara Initiative is working to address access to resources by arbitrary (as yet not introduced) entities. Not exactly the same as the "multi-owner" problem but there are some similarities.
>

---

From: Göran Selander <[email-masked]>
Date: Thu, 5 Jun 2014 12:26:01 +0000

On 03/06/14 16:15, "Carsten Bormann" <[email-masked]> wrote:

>Here in Stockholm there was a relatively extended discussion whether it
>is worth to separate the client owner and the resource owner function in
>the architecture and analogously separate out the Authorization Manager
>(less-constrained counterpart of the client) from the Authorization
>Server (less-constrained counterpart of the resource server).

As Carsten said, and please note that this was not just a discussion of
single-owner/domain vs. multi-owner/domain. This was also a discussion of
three-party vs four-party architecture. You may support the assumption of
multiple domains/owners without supporting the Authorization Manager (AM)
as a fourth node of the ACE architecture.

The role of the AM is to somehow support a constrained client in the
client domain. But none of the currently included use cases illustrate the
situation of (I) client and resource server in different domains AND (II)
the client being constrained. For example, in the case of light switches
and light bulbs, those are typically part of the same domain. If you allow
your guests to turn on lights in your home with their own device, that
device is typically something like a smartphone and not constrained.

Now, if the client and resource server are in the same domain, whatever
functionality the AM supports the client with, it could be subsumed by the
AS. If the client is not constrained, then it can perform the
functionality itself. So, do we need the AM in the architecture?

The are other use cases, e.g. during commissioning of a lightning system,
when ownership is being transferred from manufacturer of light switch to
the owner of the building. It was discussed whether this is the initial
scope for ACE and if so, whether that motivates a fourth node in the
architecture. 

(This is not trying to recap the whole discussion, just providing some
more context.)

Göran

>Obviously, this is an architectural model and does not say anything how
>these functions are mapped to specific devices in a specific deployment.
>If you don¹t separate out the functions in the architecture, I believe
>the result will be single-owner thinking and it will be very hard to
>later address the multiple-owner aspect that is so central to the
>Internet of Things idea.  Others believe that initial deployments will
>all be single-owner and it will be hard to drum up input to an
>architecture enabled for multiple owners, but it will be relatively easy
>to extend the single-owner architecture later.
>
>Grüße, Carsten
>

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 05 Jun 2014 16:33:10 +0200

Hi,

> as a fourth node of the ACE architecture.

In the actors draft, the AM is not a node but an actor. An actor is a
set of certain tasks and characteristics. AM's characteristic is that it
belongs to C's owner (CO). Its task is to safeguards CO's interests. It
does that by determining if RS is an authorized source for R and aiding
C in the authentication of RS. For C, AM is the authority for claims
about RS.

> device is typically something like a smartphone and not constrained.

I don't think the use cases document states that clearly which devices
are constrained and which are not. In many cases it depends on how
things are built. In the home automation use case, Jeffrey might use a
key-thing to enter Jane's house. In the container use case, the sensors
in the container might communicate directly with the cooling system of
the ship. In the health monitoring system, the emergency physician might
have a sensor to check John's body functions.

I don't understand why we would want to rule out scenarios where both
devices are constrained and belong to different security domains.

> scope for ACE and if so, whether that motivates a fourth node in the

Even if commissioning is not in scope for ACE it seems useful to me to
have a solution which can be used for both instead of inventing two
different mechanisms.

But maybe there is a good reason for this that I just didn't understand
yet. What do we gain from restricting the scenarios and not supporting
multi-domain constrained device to constrained device communication?

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Mon, 9 Jun 2014 05:41:48 +0000

Hi Steffi,

Thanks. We saw this discussion coming when we prepared the BOF in London.
Now that the charter has come further it is good that we try to sort out
the arguments and move forward.

>C in the authentication of RS. For C, AM is the authority for claims

Agreed, AM is not a node. To me, an actor is a business entity taking a CO
or RO role, but let¹s not get into words. I understand that AM represents
some function. One problem I have is to understand the function of AM
consistently described in the different cases where

1. AM is stand-alone
2. AM and C are co-located, and
3. AM and AS are co-located

For example ³aiding C in the authentication of RS²:

If AM is standalone, I take it is not directly authenticating the RS, but
rather authenticating to the AS somehow on behalf of C. In this case C
would have to prove to RS that it is in the domain of CO to benefit from
the authentication (and authorisation) made for AM by AS.

If AM and C are co-located, authenticating on behalf of C would be an
unnecessary indirection.

If AM and AS are co-located, AM does not have this functionality at all,
or does it?

>have a sensor to check John's body functions.

You are right that some use cases could be realized with constrained
clients in other domain than resource server. And there is nothing wrong
with such a problem  statement execpt that I am not aware that we have
specifically addressed such use cases.

>devices are constrained and belong to different security domains.

YMMV, but I find the four-party architecture more complicated than the
three-party, since we may need to consider protocols between more parties.
If we can address the use cases in scope with a three-party (multi-owner)
architecture I think this would be an advantage. I believe we could
consider other support functionality appearing in some use cases, rather
than having a permanent ³actor² making the simple use cases more
complicated.

>have a solution which can be used for both instead of inventing two

I am not saying that we should exclude commissioning, or that
commissioning necessitates an AM. We have said that we should exclude
certain key provisioning such as how the AS and RS establishes keys.
During this process some commissioning may as well take place, and thus
seems unnecessary to have a use case for.

>multi-domain constrained device to constrained device communication?

IMHO, we gain simplicity by leaving out the AM, and then we don¹t have to
work out the different cases where AM functionality is stand-alone or
coinciding with some other function.

Best regards
Göran