Subject: [Ace] I-D Action: draft-ietf-ace-actors-01.txt

From: [email-masked]
Date: Tue, 29 Sep 2015 06:04:30 -0700

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           : An architecture for authorization in constrained environments
        Authors         : Stefanie Gerdes
                          Ludwig Seitz
                          Goeran Selander
                          Carsten Bormann
	Filename        : draft-ietf-ace-actors-01.txt
	Pages           : 31
	Date            : 2015-09-29

Abstract:
   Constrained-node networks are networks where some nodes have severe
   constraints on code size, state memory, processing capabilities, user
   interface, power and communication bandwidth (RFC 7228).

   This document provides terminology, and identifies the elements that
   an architecture needs to address, providing a problem statement, for
   authentication and authorization in these networks.

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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ace-actors-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-actors-01

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/

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Sep 2015 15:27:30 +0200

This is a small update of the actors draft, 24 h before tomorrow's interim.

Note that the authors have had only very little time to review this
respin; all errors are mine.  We also have to do another round of
checking which of the comments so far have been addressed.  Definitely
not yet addressed are:

    -- tasks

(An earlier version of the draft had an extensive discussion of the
tasks actors have in achieving specific security objectives, and we may
want to relate to some of that.  It may not be necessary to hold up the
Actors document for completing this discourse, though.)

    -- maintain a clear separation between Actors and OAuth terminology

In Hawaii, the in-room rough consensus was to replace some of the Actors
terms with more or less equivalent OAuth terms, which has confused
reviewers.  With proposals on the table that use OAuth on the
less-constrained level, this starts to be even more confusing.  We can
discuss the need for this separation some more tomorrow.

    -- discuss store and forward (intermediary actors)

Probably to be added to section 2.3 based on Jim’s proposed changes.
Details not clear yet.

If you have read -00, the diff is at

Otherwise, you have 23.5 hours to read

from scratch...

Looking forward to hear you at the virtual (= Webex) interim:

  https://ietf.webex.com/ietf/j.php?MTID=m35831da47aeb861e92e275bbb13283b5
   Meeting number: 	642 579 330
   Meeting password: 	iot-rocks

Grüße, Carsten

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

---

From: Göran Selander <[email-masked]>
Date: Wed, 30 Sep 2015 09:23:45 +0000

Hi Carsten,

Coming back to your proposed agenda item.

>discuss the need for this separation some more tomorrow.

There are many things confusing here.

1. I thought we were done with terminology discussion since 6 months ago.

2. The discussion was in Dallas not in Hawaii. The current terminology has
been in use since 2015-03-25
https://datatracker.ietf.org/doc/draft-gerdes-ace-actors/04

For those who were not present or don’t the discussion: This is about
names of nodes in the architecture. The issue was discussed at length
during the first three months this year and resolved in the Dallas F2F
meeting. Here are the minutes:

https://www.ietf.org/proceedings/92/minutes/minutes-92-ace

* Actors (Carsten Bormann, 20 mins)
- There was preference to reuse OAuth terminologies (e.g. Resource Server,
Authorization Server).
- Action: Design team is requested to merge Problem Description draft and
Actors draft, and provide a combined draft.

3. There has only been one substantial review comment on this
and I consider that comment resolved with no change in current terminology.

http://www.ietf.org/mail-archive/web/ace/current/msg01242.html
http://www.ietf.org/mail-archive/web/ace/current/msg01243.html
http://www.ietf.org/mail-archive/web/ace/current/msg01244.html
http://www.ietf.org/mail-archive/web/ace/current/msg01245.html
http://www.ietf.org/mail-archive/web/ace/current/msg01246.html

4. From the reviews of the Actors draft there is no support to "maintain a
clear separation between Actors and OAuth terminology”. This is maybe a
problem with some solution proposal, such as DCAF, but you are free to
make that separation clear by selecting own terms in your proposal. If you
need to. You can always make the distinction DCAF Client vs OAuth Client
etc. Note that this kind of confusion is already present since DCAF Server
may be CoAP Client.

There is no need to change the terminology. Having an agenda item fixing
naming conflicts in primarily DCAF is not a concern of this interim.

We *could* make a clean slate terminology, I proposed that in January or
February, but I think the time has passed beyond all reasonable limits to
do that now. And you have not submitted any input for that type of
discussion so I propose we drop it.

Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 30 Sep 2015 13:19:44 +0200

Hi Göran,

maybe it helps to include Jim's comment from his review again:

"*  I find following the actor abbreviations to be difficult to follow.
It would be easier if the names were reflective of each other.  I am not
sure if you are grabbing the names from a different world in which case
this probably cannot be done. So it would be easier with   C <--> R,
CAS <--> RAS,   CO <--> RO. Trying to figure out that RqP belongs on the
C side of the world is somewhat confusing for a first time reader.
Similarly the fact that AS has a prefix for the C side but not
the R side is difficult.  As things stand one cannot discuss an AS as a
standalone entity which is a generic CAS and RAS item and contrast it
with the differences from being on one side or the other."

I take this comment serious and would like us to resolve this issue.

I don't know why you think that we need a different terminology for
DCAF. And I don't know why you think that a DCAF client can be a CoAP
server. The DCAF terminology is not the issue here. Giving a false color
to things is not really useful.

Steffi

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 30 Sep 2015 13:30:52 +0200

Stefanie Gerdes wrote:
> server. The DCAF terminology is not the issue here. 

Gute Antwort.

> Giving a false color

Und der Ausrutscher.
Sowas machen wir nicht!

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Wed, 30 Sep 2015 11:54:06 +0000

Liebe Steffi und Carsten,

I don’t know how we end up like this again. Inline.

>I take this comment serious and would like us to resolve this issue.

This was the first in a series of mails quoted below (the quote above is
missing this part: "I am not sure if you are grabbing the names from a
different world in which case this probably cannot be done.”).
I think we should also look at the later mails in this exchange.

>to things is not really useful.

I wrote DCAF server can be CoAP client. For example, in this case:

https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-03#section-3.3.
1

If the sleepy node (DCAF Server) instead implements only CoAP client
functionality (which you taught me was a valid case for very constrained
nodes back in February-ish) and uses PUT to the intermediary server,
instead of GET response.

Göran

---

From: Olaf Bergmann <[email-masked]>
Date: Wed, 30 Sep 2015 14:20:51 +0200

> nodes back in February-ish) and uses PUT to the intermediary server,

In this case you would expect the sleepy client to setup a secure
context with the intermediary using DCAF. In that case, it is a CoAP
client. But, if you instead contact the sleepy node from somewhere else
(through the intermediary) to establish an observe relationship, it
would still be the server (both CoAP and DCAF-wise).

But if, for some reason---and that was what we have talked about back
then---there is already a security association between a CoAP client and
a CoAP server that has been initiated by the CoAP client, there may be
hypothetic use cases where the application on the server side wants to
send a CoAP request to the client side utilizing the existing security
context. In that case the roles for CoAP client and server are reversed
(because the request sending party is a CoAP client and the response
sending party is a CoAP server). This is orthogonal to the role that the
entities on the lhs and rhs of your picture had when the security
context has been established. Maybe Figure 7 of draft-ietf-ace-actors-01
in Section 2.3 tries to express this. But I am not sure because I do not
understand that picture.

Grüße
Olaf

---

From: Göran Selander <[email-masked]>
Date: Wed, 30 Sep 2015 12:37:34 +0000

Hi Olaf,

I was basically thinking about publish-subscribe with end-to-end security.
I may have misunderstood, but I thought it was that  use case (or rather
the Client Pull authorization scheme) that "Piggybacked Protected Content”
was addressing.

One comment inline.

>in Section 2.3 tries to express this. But I am not sure because I do not

I think we have other review comments on that figure as well. Let’s
discuss that in the meeting.

Göran

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 30 Sep 2015 21:34:08 -0700

> -----Original Message-----
> From: Ace [mailto:[email-masked]] On Behalf Of Stefanie Gerdes
> Sent: Wednesday, September 30, 2015 4:20 AM
> To: Göran Selander <[email-masked]>; Carsten Bormann
> <[email-masked]>; [email-masked]
> Subject: Re: [Ace] I-D Action: draft-ietf-ace-actors-01.txt
> 
> Hi Göran,
> 
> It would be easier if the names were reflective of each other.  I am not sure if
> you are grabbing the names from a different world in which case
> Similarly the fact that AS has a prefix for the C side but not the R side is difficult.
> As things stand one cannot discuss an AS as a standalone entity which is a
> generic CAS and RAS item and contrast it with the differences from being on one
> side or the other."

I don't believe that my comment should be what is controlling the conversation here.  I also stated that if the terms (and abbreviations) are adopted from OAuth then using them makes sense.  

Jim

> I don't know why you think that we need a different terminology for DCAF. And I
> don't know why you think that a DCAF client can be a CoAP server. The DCAF
> terminology is not the issue here. Giving a false color to things is not really
> useful.
> 
> Steffi
> 
> >> In Hawaii, the in-room rough consensus was to replace some of the
> >> Actors terms with more or less equivalent OAuth terms, which has
> >> confused reviewers.  With proposals on the table that use OAuth on
> >> the less-constrained level, this starts to be even more confusing.
> >> We can discuss the need for this separation some more tomorrow.
> >
> >
> > 2. The discussion was in Dallas not in Hawaii. The current terminology
> > has been in use since 2015-03-25
> > - There was preference to reuse OAuth terminologies (e.g. Resource
> > Server, Authorization Server).
> > - Action: Design team is requested to merge Problem Description draft
> > and Actors draft, and provide a combined draft.
> >
> >
> >
> > 3. There has only been one substantial review comment on this and I
> > consider that comment resolved with no change in current terminology.
> >
> > 4. From the reviews of the Actors draft there is no support to
> > "maintain a clear separation between Actors and OAuth terminology”.
> > This is maybe a problem with some solution proposal, such as DCAF, but
> > you are free to make that separation clear by selecting own terms in
> > your proposal. If you need to. You can always make the distinction
> > DCAF Client vs OAuth Client etc. Note that this kind of confusion is
> > already present since DCAF Server may be CoAP Client.
> >
> >
> > There is no need to change the terminology. Having an agenda item
> > fixing naming conflicts in primarily DCAF is not a concern of this interim.
> >
> > We *could* make a clean slate terminology, I proposed that in January
> > or February, but I think the time has passed beyond all reasonable
> > limits to do that now. And you have not submitted any input for that
> > type of discussion so I propose we drop it.
> >
> >
> > Göran
> >