Subject: Re: [Ace] Relationship and difference with DICE

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Thu, 9 Jan 2014 15:55:52 +0000

Hi Hannes,

On 09/01/2014 13:21, "Hannes Tschofenig" <[email-masked]> wrote:
> 
>Yes, the section would benefit from a bit more clarity in general. I
>noticed that it is hard to follow whether we are actually talking about
>the client or the server in various paragraphs since both sides can have
>certificates (or other credentials).
>I leave that to the core working group.

There’s a draft in my pending queue if you want to share the pain :-)

> 
>As a side remark: It would be interesting to find out how likely the use
>of DNS is going to be since it raises the question about DNSSEC and how
>it interacts with various other IoT specified security mechanisms.

Yes, I think this point is very important — in fact, nominally, CoAP does
not make any assumption on DNS, thus having more data from the field would
help us shaping design decisions.

More generally the issue of giving names to actors (via CA, DNS, RD, or
any other means), and handling authorisation assertions where these names
represent the subjects or objects thereof, is at the very core of the
problem we are trying to solve.  I think we’ll need to work with CoRE to
make this a more solid ground on which to build ACE?

---

From: Göran Selander <[email-masked]>
Date: Fri, 10 Jan 2014 08:03:17 +0000

On 1/9/14 2:46 PM, "Ludwig Seitz" <[email-masked]<mailto:[email-masked]>> wrote:

On 01/09/2014 02:27 PM, Hannes Tschofenig wrote:
You are certainly right that there are potential cases where the client
asking for resources has no constraints.
But equally likely it is that the device running the resource is not
constrained but the client is.
In the worst case both devices are constrained.
  From a protocol design point of view that's obviously a tricky
situation. You can assume the worst case scenario or alternatively focus
on specific scenarios only.
That's where the requirements document would show some real value.
I wonder what the views of others in the group are.

In the use-case draft we assume that the server is constrained, and that
the client could be constrained (i.e. your worst case).

I think we never had detailed considerations on the case where only the
client is constrained, although Stefanie Gerdes had it listed on a slide
at IETF 88. My hunch is that case is much easier than the reverse one.

I viewed the constrained client and unconstrained resource server as a case which could be addressed with a proxy, reducing it to an unconstrained setting. The case of constrained resource server is more challenging. The (unconstrained) authorization server is introduced mainly because the resource server cannot be assumed to perform the authorization decision. Still the decision needs to be enforced in the resource server and moreover the decision should allow to depend on local conditions in the resource server at the time of executing the request.

In any case, you are right that client and/or resource server may or may not be constrained, and this work must ensure the compatibility between the different settings.

Göran

Gesendet: Donnerstag, 09. Januar 2014 um 13:00 Uhr
Von: "Göran Selander" <[email-masked]<mailto:[email-masked]>>
An: "Hannes Tschofenig" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Betreff: Re: [Ace] Relationship and difference with DICE

On 01/09/2014 12:28 PM, Hannes Tschofenig wrote:

PS: Btw, I would keep the main description of the ACE group as simple as
"ACE aims to enable authorized access to resources by constrained
devices.".

I would say "ACE aims to enable authorized access to resources on constrained
devices." The accessing device may be constrained or not.

Göran

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