Subject: [Ace] Last Call for Comments on ACE Charter Text

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 03 Apr 2014 08:14:40 +0200

Hi all,

we have used the time after the IETF to discuss various open issues and
we believe that we have covered all topics raised.

It is our impression that the current charter text reflects the views of
the group. Here is the latest version distributed by Kepeng a few  days
ago:
http://tools.ietf.org/wg/core/trac/wiki/ACE_charter#

Before we forward the charter text to the IESG we want to issue a 'last
call for comments'. Please provide your feedback at latest by **April
10th**.

Ciao
Hannes & Kepeng

PS: Regarding the recent proxy discussion it was our impression that no
changes to the charter text are necessary. The topic can (and should) be
covered as part of the requirements/use case discussion, which is
already explicitly stated in the charter.

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 3 Apr 2014 07:31:54 -0400

+1 (and strongly agree with the caveat that proxies should (or rather
MUST) be covered as part of the requirements/use case discussions).

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, April 03, 2014 2:15 AM
To: [email-masked]
Subject: [Ace] Last Call for Comments on ACE Charter Text

Hi all,

Ciao
Hannes & Kepeng

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 3 Apr 2014 15:26:43 +0000

The charter looks good to me. Ready to ship!

Bert

________________________________________
From: Ace [[email-masked]] on behalf of Hannes Tschofenig [[email-masked]]
Sent: 03 April 2014 14:14
To: [email-masked]
Subject: [Ace] Last Call for Comments on ACE Charter Text

Hi all,

Ciao
Hannes & Kepeng

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 4 Apr 2014 10:58:21 -0500

Hi Hannes,

I was reading the charter and noticed a few issues as follows:

> How does the digital key communicate with the lock?

I think there is something wrong with this sentence.

> Both resource server and client may be resource constraint.

I think it should be resource constrained.

There are a few other typos also.

Regards,

Behcet

On Thu, Apr 3, 2014 at 1:14 AM, Hannes Tschofenig <[email-masked]
> wrote:

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Apr 2014 17:49:42 +0200

Hi Behcet,

thanks for your review. There are indeed a couple of editorial glitches
in the charter text. I have asked my co-worker Robert Taylor to do a
review to get those fixed. Will have an updated version on the Wiki in a
few minutes.

Ciao
Hannes

On 04/04/2014 05:58 PM, Behcet Sarikaya wrote:
> On Thu, Apr 3, 2014 at 1:14 AM, Hannes Tschofenig
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi all,
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 4 Apr 2014 18:55:43 -0500

Hi Hannes,

Reading the charter, I am confused about one thing:

There is mention of clients and resource server but no mention of resource
constrained nodes or sensors. Why?

I don't think they are the clients. My guess is they are considered part of
the resource server.

I hope you can clarify.

Regards,

Behcet

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 4 Apr 2014 21:21:51 -0700

Hannes, Kepeng,

Some quick editorial remarks:

   - [typo] But in constrained environment,  -> But in constrained
   environments,
   - [suggestion] may not be available in existing protocols and for those
   cases -> may not be available in existing protocols; for those cases
   - [suggestion] will help to stimulate -> will help stimulate
   - [question] "Moreover, a standardized solution for federated
   authentication and authorization will help to stimulate the deployment of
   IoT devices offering increased security.". Do you mean that ".. with
   increased security", or "by offering solutions with increased security"
   - [suggestion] has been made the working group -> has been made, the
   working group
   - [suggestion] Furthermore, to guarantee smooth transition the
   integration -> Furthermore, to guarantee smooth transition, the integration
   - [suggestion] To be successful this working group -> To be successful,
   this working group
   - [suggestion] In the list of tasks, maybe use verbs, i.e. "Produce uses
   cases ..." and "Identify authorization ..."

Thomas

On Fri, Apr 4, 2014 at 4:55 PM, Behcet Sarikaya <[email-masked]>wrote:

> I don't think they are the clients. My guess is they are considered part
> of the resource server.
>
> I hope you can clarify.
>
> Regards,
>
> Behcet
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 05 Apr 2014 10:42:00 +0200

Thanks for taking a close look.

I updated the charter text based on your feedback.

Ciao
Hannes

On 04/05/2014 06:21 AM, Thomas Watteyne wrote:
>   * [typo] But in constrained environment,  -> But in constrained
>     environments, 
>   * [suggestion] may not be available in existing protocols and for
>     those cases -> may not be available in existing protocols; for those
>     cases
>   * [suggestion] will help to stimulate -> will help stimulate
>   * [question] "Moreover, a standardized solution for federated
>     authentication and authorization will help to stimulate the
>     deployment of IoT devices offering increased security.". Do you mean
>     that ".. with increased security", or "by offering solutions with
>     increased security"
>   * [suggestion] has been made the working group -> has been made, the
>     working group
>   * [suggestion] Furthermore, to guarantee smooth transition the
>   * [suggestion] To be successful this working group -> To be
>     successful, this working group
>   * [suggestion] In the list of tasks, maybe use verbs, i.e. "Produce
>     uses cases ..." and "Identify authorization ..."
> 
> Thomas
> 
> 
> On Fri, Apr 4, 2014 at 4:55 PM, Behcet Sarikaya <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi Hannes,
> 
>     There is mention of clients and resource server but no mention of
>     resource constrained nodes or sensors. Why?
> 
>     I don't think they are the clients. My guess is they are considered
>     part of the resource server.
> 
>     I hope you can clarify.
> 
>     Regards,
> 
>     Behcet
> 
> 
>     On Fri, Apr 4, 2014 at 10:49 AM, Hannes Tschofenig
>         > <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>         >
>         >     Hi all,
>         >
>         >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 05 Apr 2014 10:46:19 +0200

Hi Behcet,

this is a terminology issue.

Depending on the setup you might have a smart phone talking to a sensor
or a sensor talking to some other device.

We just call these client and resource server. The resource server hosts
the protected resource and the client wants to access it.

Who is, in the specific scenario, the constrained device depends on the
setup but either the client or the resource server may be constrained.
The authorization server, as we discussed on the list, is not
constrained in the same way as the client and the resource server.

It might be difficult to also capture these terminology aspects and use
cases within the charter itself. For that purpose the interested reader
will have to look at the documents.

Does this explanation help?

Ciao
Hannes

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 7 Apr 2014 11:36:05 -0500

Hi Hannes,

I am confused how the terminology would apply to this example
from the charter:

a door lock has to authorize the person seeking access using a "digital
key".

I don't we can authorize persons in IETF?

Also I believe the charter should concentrate on authentication, currently
it talks more about authorization.
Authorization without AAA infrastructure is difficult I think.

Maybe you can clarify a bit in this sentence:
the need arises for a dynamic and fine grained access control mechanism,
where clients and/or resource servers are constrained.

Door lock representing the resource (resource server) with constrained
node(s) authenticates the client which is the key representing the person
with the help of an authentication server, etc.

Is there an example whereby the client would be the constrained node? Maybe
NFC use case?

Regards,

Behcet

On Sat, Apr 5, 2014 at 3:46 AM, Hannes Tschofenig <[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 7 Apr 2014 18:46:15 +0200

On 07 Apr 2014, at 18:36, Behcet Sarikaya <[email-masked]> wrote:

> a door lock has to authorize the person seeking access using a "digital key". 
> 

People are indeed authenticated; one typically authorizes a person for specific actions only.
(I read the existing text as a statement about authorizing an action, “the person seeking access”; this could be clarified.)

> Also I believe the charter should concentrate on authentication,

That is the part for which we have enough protocols already.

> currently it talks more about authorization.

Which is exactly what it should do; authentication is ancillary to the objective of authorization.

> Authorization without AAA infrastructure is difficult I think.

That statement depends so much on the definitions of “AAA” and “infrastructure” that I don’t know how assign a truth value to it.

> Is there an example whereby the client would be the constrained node? Maybe NFC use case?

The client might be a light switch, and the server might be a lamp.

Grüße, Carsten

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 7 Apr 2014 13:39:55 -0500

Hi Carsten,

Thanks for your reply.

No, I am not going away :-)

Please see inline below.

On Mon, Apr 7, 2014 at 11:46 AM, Carsten Bormann <[email-masked]> wrote:

> (I read the existing text as a statement about authorizing an action, "the
> person seeking access"; this could be clarified.)
>
>
Yes, please.

> objective of authorization.
I don't think there is something called authorization protocol.
Oauth talks about authorization grant not authorization protocol.
Maybe an authorization protocol would be search in a database but none
wants to do it.

> That statement depends so much on the definitions of "AAA" and
> "infrastructure" that I don't know how assign a truth value to it.
>
>
See above. I meant the use in an operator's domain.

> You mean light switch would be authorized to access the lamp?

Regards,

Behcet

---

From: Göran Selander <[email-masked]>
Date: Tue, 8 Apr 2014 13:07:49 +0000

>objective of authorization.

I think there is one point here that should be clarified in the charter.
The title of this proposed WG is "Authentication and authorisation in
Constrained Environments² (not "Authorisation in Constrained
Environments²) and for a good reason. Authorisation depends on
authentication, and we want to allow authentication and authorisation to
be based on common trust roots (provisioned keys etc.) and common key
management:

- Clearly we don¹t want one procedure for provisioning keys for verifying
the integrity of authorisation information and a another procedure for
provisioning keys for authentication of each client.

- Also, to bind the authorisation of a client to a particular requesting
client, the resource server must have access to a key representing the
client identified in the authorisation information.

- Moreover keys for authorisation needs to be managed, renewed at certain
times, etc. just like keys for authentication.

I would like to have a sentence or two in the charter clarifying this. How
about the following:

"A common key management solution for authentication and authorisation
will be provided to optimise key provisioning in constrained devices."

Put in context below:

Existing authentication and authorization protocols will be used and
re-applied for use in constrained environments where applicable. _A common
key management solution for authentication and authorisation will be
provided to optimise key provisioning in constrained devices._
This requires relevant specifications to be reviewed for suitability,
selecting a subset of them and restricting the options within each of
the specifications. Some functionality, however, may not be available in
 existing protocols and thus new standardization efforts will be
required. Leveraging existing work means the working group benefits from
 available security analysis, implementation, and deployment experience.
 Moreover, a standardized solution for federated authentication and
authorization will help to stimulate the deployment of constrained
devices that provide increased security.

Göran

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 8 Apr 2014 11:29:24 -0500

> will be provided to optimise key provisioning in constrained devices."
This sounds good but I am not sure if it applies to the case where the
client is not a constrained device?

Regards,

Behcet

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 08 Apr 2014 22:16:01 +0200

Hi Behcet, Hi Göran, Hi Carsten,

thanks for the feedback.

I am wondering whether we are stretching the concept of a charter text
here a bit too much. I am saying that because the charter is a teaser
for the reader to continue looking in the rest of the documents. It is
not a replacement for actually reading the specs and it is also not a
tutorial.

Behcet, have you had a chance to look at the requirements / use case
document that provider further background?

Ciao
Hannes

On 04/08/2014 06:29 PM, Behcet Sarikaya wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>     On 07/04/14 18:46, "Carsten Bormann" <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>     >On 07 Apr 2014, at 18:36, Behcet Sarikaya <[email-masked]

---

From: Göran Selander <[email-masked]>
Date: Wed, 9 Apr 2014 06:29:35 +0000

>not a replacement for actually reading the specs and it is also not a

In addition to be a teaser, isn¹t another objective of the charter to
clarify the work to be done? Currently there is no explanation how
authentication and authorisation should work together. There are 15+
drafts on the list of existing work and in those very little guidance on
this topic.

You may call it obvious or a tutorial, to explicitly state that the
solution should allow a common key management for authentication and
authorisation. I can imagine people with a different mindset think of
solutions which require you to provision to the resource server both

(a) keys of the authorisation server(s), and
(a) keys for each candidate client.

For some use cases this is not a problem, but e.g. looking at the
spontaneous change of access control policies, the authorisation of a
client hitherto unknown to the resource server should not require making
an out-of-band provisioning of client keys to the resource server.

(And if it is obvious then there is little harm adding one sentence,
right?)

Göran

---

From: Göran Selander <[email-masked]>
Date: Wed, 9 Apr 2014 06:31:22 +0000

Hi Behcet,

From: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>

This sounds good but I am not sure if it applies to the case where the client is not a constrained device?

I thought of this mainly from the point of view of a provisioning to constrained devices, but it should also apply in general. How about this:

"A common key management solution for authentication and authorisation
will be provided to optimise key provisioning."

Göran

---

From: Göran Selander <[email-masked]>
Date: Wed, 9 Apr 2014 06:32:01 +0000

Yes

---

From: Robert Cragie <[email-masked]>
Date: Wed, 09 Apr 2014 08:12:37 +0100

+1 - the charter should not start to focus on solutions. I think it is 
good as it is.

Robert

---

From: Sandeep Kumar <[email-masked]>
Date: Wed, 9 Apr 2014 11:37:44 +0200

+1.
I also second Göran on including a single provisioning method for the
operational keys for both authentication and authorization. The final ACE
solution should be able to sketch how the key management can be performed.

regards
Sandeep

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 9 Apr 2014 12:22:39 +0200

On 09 Apr 2014, at 11:37, Sandeep Kumar <[email-masked]> wrote:

> single provisioning method

I don’t think viewing authorization as a “provisioning” problem yields a complete view of the problem.
(But this is in solution space again...)

Grüße, Carsten

---

From: Corinna Schmitt <[email-masked]>
Date: Wed, 09 Apr 2014 12:35:08 +0200

I agree Sandeep that we also have to look on how the key management can 
be performed.
Furthermore we have to take care of all authorization facets at the same 
time. Here limitation to "provisioning" method is not constructive.

Regards,
Corinna

Am 09.04.14 11:37, schrieb Sandeep Kumar:
> operational keys for both authentication and authorization. The final 
> ACE solution should be able to sketch how the key management can be 
> performed.
>
> regards
> Sandeep
>
>
>     >Which is exactly what it should do; authentication is ancillary
>     to the
>     >objective of authorization.
>

--

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 09 Apr 2014 18:18:05 +0200

> time. Here limitation to "provisioning" method is not constructive.

I think there is some misunderstanding here about what Göran means. The 
idea is not to limit our work to provisioning, but provisioning will 
need to be a part of a solution, and then we want to make sure the 
provisioning methods we use for authentication can be reused for 
authorization.

/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: Thu, 10 Apr 2014 05:51:05 +0000

>provisioning methods we use for authentication can be reused for

Something like that, let me try again:

In some (probably many) use cases, when a device leaves the factory it
does not know who will be its owner, authorisation server, authorised
clients (if it is a resource server) etc.

In some of those cases, there is a provisioning procedure after
manufacture whereby keys are established in the device.

In some of those cases, the device is intended to be fully operational
thereafter, in particular that a device can authenticate and authorise
requests with keys derived through a common key management scheme using
the established keys, without any further provisioning.

My hope is that a solution produced in ACE will support this setting as an
option, and that such a key management scheme is specified. IMHO this is
not removing any desirable solutions from the solution space. Simplifying
the proposed text even further:

will be specified."

Göran

---

From: Corinna Schmitt <[email-masked]>
Date: Thu, 10 Apr 2014 08:25:15 +0200

Thanks Ludwig for clarification.
That makes more sense to me and fits to our draft idea.

Regards,
Corinna

Am 09.04.14 18:18, schrieb Ludwig Seitz:
> I think there is some misunderstanding here about what Göran means. 
> The idea is not to limit our work to provisioning, but provisioning 
> will need to be a part of a solution, and then we want to make sure 
> the provisioning methods we use for authentication can be reused for 
> authorization.
>
> /Ludwig
>
>
>

--

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Apr 2014 08:27:13 +0200

> the established keys, without any further provisioning.

Yes, but the end of “provisioning" doesn’t mean there is no further communication about establishing authenticated authorization.

> "A common key management solution for authentication and authorisation

I’m afraid that sentence says something different, approximately “all of authentication and authorization will be based on a common ‘key management’”.  (I don’t know what ‘key management’ is, but this sentence also invites all the worst interpretations.)

Grüße, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Thu, 10 Apr 2014 08:04:03 +0100

I completely agree with Carsten. What is a "key management solution"? I 
would rather not see the word "key" used in the charter (and I don't 
count "digital key" as that is a generalisation in the context of a door 
lock) or any language which attempts to constrain the possible 
solutions. All the charter should do is set the context and identify the 
tasks and products, which is does.

Robert

---

From: Rene Struik <[email-masked]>
Date: Thu, 10 Apr 2014 17:58:43 -0400

Hi Hannes:

I had a look at the charter text. I do agree with the two tasks 
identified in the charter.

I do have some some comments on the (rather lengthy) prelude to the 
enumeration of these two tasks. These comments do not matter if the 
group agrees that the charter does not try and steer into a particular 
solution direction (as some comments on the list have indeed suggested 
to be the case). My comments are worded in case this is not so.

Small comments:
a) 2nd para, l. 3: replace "authorization decisions" by "authorization 
criteria" or "authorization policy". After all, decisions are not 
stored, but acted upon.
b) 2nd para, l. -1: replace "resource server" by "resource owner", 
"resource holder", or similar. This would make it clearer that the 
"server" is the device that actually stores the info the client is 
soliciting.
c) 4th para, l.. -1: not sure what the exact context of "consent of the 
user" is. Aren't we talking about device-to-device communications, where 
user may only be involved with configuration decisions (and, perhaps, 
even only remotely).
d) 6th para, l. 4: replace "will be required" by "may be required".

Main comments:
a) 3rd para: This whole para seems to presort solutions, by suggesting 
that one wishes to look at three-party protocols. Moreover, why would 
one care whether IETF had a "tradition" to develop something (for a 
completely different setting than constrained devices and networks)? The 
example protocols are a disparate set, where Kerberos and AAA require 
inline third parties and, e.g., authenticated public-key based key 
agreement only uses a CA as offline third party (or does the word "PKI" 
imply here OCSP, CRLs, etc, as well?). In all cases, it is not entirely 
clear whether these all serve to provide authentication and fine-grained 
authorization objectives. I would suggest scrapping this whole para.
b) 4th para: I would scrap any hint at suitability of solutions and go 
into this effort with an open mind (i.e., scrap "suitability of existing 
work, such as OAuth", etc.).
c) 5th para: by stipulating that client and server are constrained, but 
authorization server is not, one rules out any implementation where the 
authorization server coincides with client or server. This seems 
imprudent, since authorization decisions on client request by the server 
can be based on (1) locally maintained info (access control list style); 
(2) information included with the client request message flow; (3) info 
obtained from a third-party helper device that assists the server with 
this decision. The way things are currently phrased seems to be steer 
this into direction #3. Again, please keep an open mind and do not 
pre-bake solution directions in the charter.
d) 6th para: I would not over-estimate the existing "deployment 
experience", nor "available security analysis" (there is quite some 
crypto and security literature that IETF never tapped and some of the 
security properties of widely used IETF protocols is being heavily 
disccussed/criticized on other lists (tls list)). In my mind, referring 
to "IETF tradition" and "benefit of security analysis", etc., could 
therefore be somewhat dangerous.
e) 7th para: I would suggest scrapping the entire para, since much too 
ambitious (one can easily recharter to take on more work or refocus at a 
later stage). This is especially so, since expertise with security, 
privacy, and good understanding of usability (as alluded to in the 8th 
para) is in rather short supply (one may of course disagree here).

*Draft Charter V0.9a - Authentication and Authorization for Constrained 
Environment (ACE)*

The IETF has recently developed protocols for use in constrained 
environments, where network nodes are limited in CPU, memory and power. 
It has been observed that Internet protocols can be applied to these 
constrained environments, often only requiring minor tweaking and 
profiling. In other cases, new protocols have been defined to address 
the specific requirements of constrained environments. An example of 
such a protocol is the Constrained Application Protocol (CoAP).

As in other environments, authentication and authorization questions 
also arise in constrained environments. For example, a door lock has to 
authorize the person seeking access using a "digital key". Where are the 
authorization decisions stored? How does the digital key communicate 
with the lock? Does the lock interact with an authorization server to 
obtain authorization information? How can access be temporarily granted 
to other persons? How can access be revoked? These types of questions 
have been answered by existing protocols for use cases outside 
constrained environments, however in constrained environments, 
additional and different requirements pose challenges for the use of 
various security protocols. In particular, the need arises for a dynamic 
and fine grained access control mechanism, where clients and/or resource 
servers are constrained.

The IETF has a long history in developing three-party authentication and 
authorization protocols for distributed environments. Examples include 
Kerberos, the Public Key Infrastructure (PKI), the Authentication, 
Authorization and Accounting (AAA) infrastructure, and the Web 
Authorization Protocol (OAuth). All these protocols enjoy widespread 
deployment on the Internet. Although they all aim to solve a similar 
goal, at an abstract level, they offer quite different functions and 
utilize different message exchanges. These differences result from the 
main deployment use cases they were designed for respectively.

Requirements derived from use cases indicate the suitability of existing 
work, such as OAuth, as a solution for constrained environments. These 
protocols, however, were not optimized for constrained environments. 
Additional requirements that need to be taken into account are the lack 
of a suitable user-interface for obtaining the consent of the user and 
the inability of embedded devices to contact an authorization server in 
real-time with every resource access request due to intermittent 
connectivity, etc.

This working group therefore aims to produce a standardized solution for 
authentication and authorization to enable authorized access to 
resources 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. This access will be 
mediated by an authorization server, which is not considered to be 
constrained.

re-applied for use in constrained environments where applicable. This 
requires relevant specifications to be reviewed for suitability, 

Once progress in identifying suitable candidate solutions has been made, 
the working group will verify whether the same mechanisms are also 
applicable beyond the use of CoAP and DTLS, which are the two main 
protocols the group will focus on for access to resources. In 
particular, the ability to use the developed solution over HTTP and TLS 
will be investigated. Furthermore, to guarantee smooth transition, the 
integration with existing deployments will be studied, particularly 
concerning the use of protocol translation proxies.

To be successful, this working group requires expertise in security, 
privacy, and a good understanding of usability in constrained 
environments. This work does not make the assumption that the party 
offering application layer services is always the same party offering 
network access services.

The working group has the following tasks:

1) Produce use cases and requirements

2) Identify authentication and authorization mechanisms suitable for 
resource access in constrained environments.

Milestones:

  * Jul 2014 Submit "Use cases and Requirements" as a WG item.
  * Dec 2014 Submit "Authentication and Authorization Solution" as a WG
    item.
  * Jul 2015 Submit "Use cases and Requirements" document to the IESG
    for publication as an Informational RFC.
  * Jul 2016 Submit "Authentication and Authorization Solution"
    specification to the IESG for publication as a Proposed Standard.

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

---

From: Göran Selander <[email-masked]>
Date: Fri, 11 Apr 2014 05:23:27 +0000

Hi Carsten, Robert,

Hannes kindly provided the context in a recent mail. I get the part that
this is perhaps not so easy to formulate in a sentence, and saying more
would probably go too much into details. However, I maintain that the
example is relevant and will return to that in the requirements discussion.

Göran

On 10/04/14 09:04, "Robert Cragie" <[email-masked]> wrote:

>> Yes, but the end of ³provisioning" doesn¹t mean there is no further
>>communication about establishing authenticated authorization.
>>
>> I¹m afraid that sentence says something different, approximately ³all
>>of authentication and authorization will be based on a common key
>>management¹².  (I don¹t know what key management¹ is, but this sentence
>>also invites all the worst interpretations.)
>>
>> Grüße, Carsten
>>

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 11 Apr 2014 09:04:11 +0200

On 04/10/2014 11:58 PM, Rene Struik wrote:
> enumeration of these two tasks.

I tried to raise attention to the "rather lengthy" aspect of the charter 
descriptive text earlier. I still maintain it would be more accessible 
and inviting if it was shorter, but I won't insist if the majority 
thinks the "wall of text" approach is the way to go.

...
> pre-bake solution directions in the charter.

I'd actually like to put (1) out of scope for this WG, since that would 
be duplicating work by OMA-LW-M2M (or worse, proposing a competing 
incompatible approach). If someone thinks it would be useful to redo 
this, please explain.

/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: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 14 Apr 2014 14:25:16 +0200

Hi Rene, 
 
thanks for the review comments. I have updated the charter text accordingly.
 
A few remarks inline: 

Gesendet: Donnerstag, 10. April 2014 um 22:58 Uhr
Von: "Rene Struik" <[email-masked]>
An: "Hannes Tschofenig" <[email-masked]>, "[email-masked]" <[email-masked]>
Betreff: Re: [Ace] Last Call for Comments on ACE Charter Text

Hi Hannes:

I had a look at the charter text. I do agree with the two tasks identified in the charter.

I do have some some comments on the (rather lengthy) prelude to the enumeration of these two tasks. These comments do not matter if the group agrees that the charter does not try and steer into a particular solution direction (as some comments on the list have indeed suggested to be the case). My comments are worded in case this is not so.

Small comments:
a) 2nd para, l. 3: replace "authorization decisions" by "authorization criteria" or "authorization policy". After all, decisions are not stored, but acted upon.
 
[hannes] Fixed.
 
b) 2nd para, l. -1: replace "resource server" by "resource owner", "resource holder", or similar. This would make it clearer that the "server" is the device that actually stores the info the client is soliciting.

[hannes] I changed the wording to make clear that we are talking about the server that is holding the resource. 

c) 4th para, l.. -1: not sure what the exact context of "consent of the user" is. Aren't we talking about device-to-device communications, where user may only be involved with configuration decisions (and, perhaps, even only remotely).

[hannes] I removed the consent part to avoid the need to talk about it. Just referring to user interface limitations of many of these IoT devices is sufficient. ;

[hannes] Fixed. 

Main comments:
a) 3rd para: This whole para seems to presort solutions, by suggesting that one wishes to look at three-party protocols. Moreover, why would one care whether IETF had a "tradition" to develop something (for a completely different setting than constrained devices and networks)? The example protocols are a disparate set, where Kerberos and AAA require inline third parties and, e.g., authenticated public-key based key agreement only uses a CA as offline third party (or does the word "PKI" imply here OCSP, CRLs, etc, as well?). In all cases, it is not entirely clear whether these all serve to provide authentication and fine-grained authorization objectives. I would suggest scrapping this whole para.

[hannes] With a recent charter text change the text does not talk about tradition anymore. So, that concern is gone. Overall, the idea of the paragraph is to highlight that there is some work the group will take a look at. Of course, the different approaches offer different properties. Which of those mechanisms is suitable depends heavily on the work on the use cases and the requirements; hence, it is a bit premature to dismiss some of them already now. 

b) 4th para: I would scrap any hint at suitability of solutions and go into this effort with an open mind (i.e., scrap "suitability of existing work, such as OAuth", etc.).

[hannes] I remoted the explicit mentioning of OAuth in the charter text. 

c) 5th para: by stipulating that client and server are constrained, but authorization server is not, one rules out any implementation where the authorization server coincides with client or server. This seems imprudent, since authorization decisions on client request by the server can be based on (1) locally maintained info (access control list style); (2) information included with the client request message flow; (3) info obtained from a third-party helper device that assists the server with this decision. The way things are currently phrased seems to be steer this into direction #3. Again, please keep an open mind and do not pre-bake solution directions in the charter.
d) 6th para: I would not over-estimate the existing "deployment experience", nor "available security analysis" (there is quite some crypto and security literature that IETF never tapped and some of the security properties of widely used IETF protocols is being heavily disccussed/criticized on other lists (tls list)). In my mind, referring to "IETF tradition" and "benefit of security analysis", etc., could therefore be somewhat dangerous.

[hannes] I am following the feedback from the group on the issue of the constrained nature of the authorization server not being constrained in the same way as the client or the resource server. If you have use cases where the authorization server is co-located with the client and/or the resource server please bring them forward. Note that I believe nobody says anything about the potential caching of information at the client or the server-side. 

Regarding the deployment experience and the security analysis: Of course, different persons have various preferences regarding the re-use of existing technology. Some people may want to re-use their existing code, they want to integrate with existing deployments, they want to benefit from available open source, re-use existing building blocks. There will be others who want to start from scratch. I believe that this issue will be resolved in the requirements discussion and in the work on the actual solutions. 

e) 7th para: I would suggest scrapping the entire para, since much too ambitious (one can easily recharter to take on more work or refocus at a later stage). This is especially so, since expertise with security, privacy, and good understanding of usability (as alluded to in the 8th para) is in rather short supply (one may of course disagree here).

[hannes] I deleted the first sentence since it did not constrain the work in any way. However, the second sentence does reflect the intention of the group with shaping the work: "This work does not make the assumption that the party offering application layer services is always the same party offering network access services." 

Ciao
Hannes

---

From: Robert Cragie <[email-masked]>
Date: Tue, 15 Apr 2014 16:53:23 +0100

A couple of small comments inline. I am OK with the rest of the changes.

Robert

> a) 2nd para, l. 3: replace "authorization decisions" by "authorization criteria" or "authorization policy". After all, decisions are not stored, but acted upon.
<RCC>I have no particular issue with the change but I think it was OK as 
it was, as an authorization *policy* can often be static, therefore not 
requiring storage. Decisions certainly are stored and form the basis for 
access control.</RCC>
> [hannes] I changed the wording to make clear that we are talking about the server that is holding the resource.
<RCC>The way it is written now could read that clients can hold 
resources - not the case in a REST architecture. Again, I thought it was 
OK as it way</RCC>

---

From: Likepeng <[email-masked]>
Date: Wed, 16 Apr 2014 10:48:12 +0000

> <RCC>The way it is written now could read that clients can hold resources -
> not the case in a REST architecture. Again, I thought it was OK as it way</RCC>

I have the same feeling as Robert. From the wording, it seems that the clients can hold resources.

In fact, in the charter, there is another sentence which clarifies the resources are stored at resource server:
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.

So Rene's concern can be gone.

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 Robert Cragie
> 发送时间: 2014年4月15日 23:53
> 收件人: Hannes Tschofenig; Rene Struik
> 抄送: [email-masked]
> 主题: Re: [Ace] Last Call for Comments on ACE Charter Text
> 
> > b) 2nd para, l. -1: replace "resource server" by "resource owner", "resource
> holder", or similar. This would make it clearer that the "server" is the device
> that actually stores the info the client is soliciting.
> >
> <RCC>The way it is written now could read that clients can hold resources -
> not the case in a REST architecture. Again, I thought it was OK as it way</RCC>

---

From: Likepeng <[email-masked]>
Date: Wed, 16 Apr 2014 10:58:24 +0000

> <RCC>I have no particular issue with the change but I think it was OK as it was, as an authorization *policy* can often be static, therefore not requiring storage. Decisions certainly are stored and form the basis for access control.</RCC>

For this one, I tend to agree with Rene. Decisions are not stored, but acted upon. For example, if the decision is "yes", open the door. There is no need to store the "yes".

Kind Regards
Kepeng

> enumeration of these two tasks. These comments do not matter if the group
> agrees that the charter does not try and steer into a particular solution
> direction (as some comments on the list have indeed suggested to be the case).
> My comments are worded in case this is not so.
> >
> > Small comments:
> > a) 2nd para, l. 3: replace "authorization decisions" by "authorization criteria"
> or "authorization policy". After all, decisions are not stored, but acted upon.
> >
> > [hannes] Fixed.
> <RCC>I have no particular issue with the change but I think it was OK as it was,
> as an authorization *policy* can often be static, therefore not requiring
> storage. Decisions certainly are stored and form the basis for access
> control.</RCC>
> >

---

From: Robert Cragie <[email-masked]>
Date: Wed, 16 Apr 2014 12:41:17 +0100

OK - I have no problem with the change. No further comments.

Robert

---

From: Likepeng <[email-masked]>
Date: Mon, 21 Apr 2014 08:46:21 +0000

Receiving no other feedback, I made the change to the charter.

OLD:
where clients and/or servers holding resources are constrained.

NEW:

Now it is v0.9c, quite close to 1.0. :-)
http://trac.tools.ietf.org/wg/core/trac/wiki/ACE_charter#

Please take a final check to see if your comments have been resolved in this version.

Thanks,

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 Likepeng
> 发送时间: 2014年4月16日 18:48
> 收件人: [email-masked]; Hannes Tschofenig; Rene Struik
> 抄送: [email-masked]
> > resources - not the case in a REST architecture. Again, I thought it
> > was OK as it way</RCC>
> 
> 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.
> 
> > > "resource
> > holder", or similar. This would make it clearer that the "server" is
> > the device that actually stores the info the client is soliciting.
> > >
> > > [hannes] I changed the wording to make clear that we are talking
> > > about the
> > server that is holding the resource.
> > resources - not the case in a REST architecture. Again, I thought it
> > was OK as it way</RCC>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 22 Apr 2014 10:29:25 +0200

Good for me, Kepeng!