Subject: [Ace] Benoit Claise's Block on charter-ietf-ace-00-01: (with BLOCK)

From: "Benoit Claise" <[email-masked]>
Date: Wed, 14 May 2014 15:12:15 -0700

Benoit Claise has entered the following ballot position for
charter-ietf-ace-00-01: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/charter-ietf-ace/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

Reaction from the AAA-doctors.

1.
 I haven't been following it in detail, but it does seem rather vague.

...
This working group therefore aims to produce a standardized solution for
authentication and authorization to enable authorized access to
resources in constrained environments.
...

  What are "resources?  It seems they are applications, but the charter
doesn't make that clear.  Also, if the "constrained environments" are
using DTLS, they don't seem that constrained to me.

  It looks to be a slight variation on existing technologies.  e.g. we
want X, Y and Z, but in situation B instead of A.  So... we're going to
design something completely new.

  On the other hand, I'm happy to see people paying attention to
authentication and authorization.  Too many protocols are designed to
solve a problem first, and second to add security.

2. 
The Charter makes a number of assertions that are provably false, such as
that AAA protocols are inappropriate for constrained environments. AAA
protocols were deployed in the 1990s to support extremely limited NAS
devices and Internet hosts with tiny fractions of the power of today's
systems.  Any device that can run IP can authenticate against a AAA
server.

Let me include the AAA-doctors in the discussion

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 15 May 2014 10:26:43 +0200

...
> Let me include the AAA-doctors in the discussion

I guess the crucial point here is the ways constrained environments are 
used today and what is expected of them (e.g. in terms of response time, 
number of deployed devices, criticality of the infrastructure they 
control).
This is quite different from what was expected from NAS devices and 
Internet hosts in the 1990s. Another important factor is that many 
constrained devices are battery powered and thus need to operate quite 
differently from what Internet hosts and NAS devices would do in 1990.

Even AAA protocols have made some progress since 1990s (or we would 
still be sitting in a cave carving Access Control Matrices into stone 
tablets).

So I would indeed argue that many of the AAA protocols deployed today 
are not suitable for constrained devices without some profiling or 
adaptation (we already have the DICE WG for example, that is working on 
adapting DTLS to constrained environments).

/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: Alan DeKok <[email-masked]>
Date: Thu, 15 May 2014 09:07:23 -0400

Ludwig Seitz wrote
> adaptation

  Adaptation to *what*?  That's the part I'm missing.

  Speaking from the RADIUS side, a well-done client is ~5K LoC.  A
simple server is more, but not a lot more.  They can each do 1000's of
packets per second on commodity hardware with a naive implementation, at
low latencies.

  I don't see a need for much in the way of profiling.  Just a clear
description of the problem being solved.

  Alan DeKok.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 May 2014 09:37:59 -0400

> Speaking from the RADIUS side, a well-done client is ~5K LoC.  A

The problem that we are dealing with is not really authentication at all.
I don't know how to use radius from the constrainted device at all.
I don't even know how to setup the radius shared secret at all.

Radius/Diameter have a place, but it is behind an authorization server.

    > description of the problem being solved.

Let Device X update resource Y on Device Z.
That's the problem statement.

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

---

From: Robert Cragie <[email-masked]>
Date: Thu, 15 May 2014 15:34:30 +0100

First, the charter does not say that "AAA protocols are inappropriate 
for constrained environments". It says existing work was not optimized 
for constrained environments, which is the case.

Michael's problem statement below is spot on. All the charter should say 
is words to the effect of: "Let's look at that being done using CoAP 
(HTTP) and DTLS (TLS) first. Then let's take what we came up with and 
see if it would be useful elsewhere". However I don't support saying 
"Other application protocols with their related
transport protocols, and other protocols at other layers in the stack, 
are out of scope"; they are not the original focus but it is important 
to consider how we could reuse identified and developed protocols for 
e.g. network access and indeed AAA to improve efficiency in constrained 
devices.

Robert

On 15/05/2014 2:37 PM, Michael Richardson wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Alan DeKok <[email-masked]>
Date: Thu, 15 May 2014 10:36:43 -0400

> for constrained environments, which is the case.

  That all depends what you mean by "constrained".  If you read it as
"small low-power, low-memory systems", then it's not true.  AAA
protocols work there just fine.

  If by "constrained", you mean "a mesh of small devices all of whom
which to update resources on each other", then it is true.  But it's a
very off definition of "constrained".

  I would suggest avoiding the word "constrained", and replacing it with
something a bit more descriptive.

  Alan DeKok.

---

From: Corinna Schmitt <[email-masked]>
Date: Thu, 15 May 2014 17:02:41 +0200

From UZH I can say AAA works fine with very small device.
We described it in our draft. Currently we just specify the minimum RAM 
and ROM requirements that must be fulfilled, but in general it works fine.

Regards,
Corinna

--

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 15 May 2014 17:29:22 +0200

On 15 May 2014, at 17:02, Corinna Schmitt <[email-masked]> wrote:

> very small

RFC 7228 has some more specific terminology here.

We know that EAP/PANA can be made to work for network authentication in single-domain networks built out of class-2 devices.
(This is the SE2.0 scenario.)

ACE is trying to do application layer authorization within networks that include class-1 devices.
A single-domain solution is most likely not sufficient from a problem statement point of view.
(And the multiple domains may be more complicated than the essentially just federated eduroam-style multi-domain network.)

So I think the jury is still out on the complexity issue.

What became pretty clear in our recent ABFAB tutorial call is that this is not a plug-and-play situation with the existing protocols that make ABFAB work.  Some development (and not just assembly) required.

But the more important question really is whether the ABFAB model of players and roles fits with what needs to be done in a typical constrained-node network.  For one, NAIs are a great answer, just not necessarily to our questions.

Grüße, Carsten

---

From: Paul Duffy <[email-masked]>
Date: Thu, 15 May 2014 12:17:18 -0400

Folks,

This is the second inquiry re: the charter and the term "resource".  
Taken for granted by REST-heads, mysterious otherwise.

The charter often uses the expression "constrained environments".

Somewhere near the top define  or reference "RESTful constrained 
environments", then use "RESTful constrained environments" throughout.

On 5/14/2014 6:12 PM, Benoit Claise wrote:
> .

---

From: Robert Cragie <[email-masked]>
Date: Thu, 15 May 2014 18:18:43 +0100

There is a difference between existing working protocols "working just 
fine" and whether they are optimized for constrained environments. TLS 
is also a case in point - it "works just fine" in Class 1 constrained 
nodes (RFC 7228) even with ephemeral ECDH and X.509 certificates. On 
that basis, the charter is not excluding anything.

I don't mind using the word "constrained" in the context of RFC 7228.

Robert

---

From: Likepeng <[email-masked]>
Date: Thu, 15 May 2014 21:13:50 +0000

>What are "resources?  It seems they are applications, but the charter doesn't make that clear.

I think I have explained in another thread. Resources are not applications, and the resource concept is taken from HTTP protocol.

About the "resource", we can take the definition from RFC2616:

   resource
      A network data object or service that can be identified by a URI,
      as defined in section 3.2. Resources may be available in multiple
      representations (e.g. multiple languages, data formats, size, and
      resolutions) or vary in other ways.

For example, resources can be temperature sensors on a data collection node, or a list of alarms on a home security controller. [RFC6690]

Maybe we can add two explanations: one is that resources can be identified by a URI, two is that resources are hosted on the resource server.

"Access to a resource" means Get, Put, Post and Delete to a resource.

>...
>This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access to resources in constrained environments.
>...

This sentence has been revised to:

NEW
This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access (Get, Put, Post, Delete) to resources identified by a URI and hosted on a resource server in constrained environments.
END

Hope it clarifies.

Thanks,
Kind Regards
Kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 Benoit Claise
发送时间: 2014年5月15日 6:12
收件人: The IESG
抄送: [email-masked]; [email-masked]
主题: [Ace] Benoit Claise's Block on charter-ietf-ace-00-01: (with BLOCK)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

1.

...
This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access to resources in constrained environments.
...

  What are "resources?  It seems they are applications, but the charter doesn't make that clear.  Also, if the "constrained environments" are using DTLS, they don't seem that constrained to me.

  It looks to be a slight variation on existing technologies.  e.g. we want X, Y and Z, but in situation B instead of A.  So... we're going to design something completely new.

  On the other hand, I'm happy to see people paying attention to authentication and authorization.  Too many protocols are designed to solve a problem first, and second to add security.

2. 
The Charter makes a number of assertions that are provably false, such as that AAA protocols are inappropriate for constrained environments. AAA protocols were deployed in the 1990s to support extremely limited NAS devices and Internet hosts with tiny fractions of the power of today's systems.  Any device that can run IP can authenticate against a AAA server.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 16 May 2014 12:31:29 -0700

> packets per second on commodity hardware with a naive implementation, at
[BA] I have run global networks with RADIUS servers based on hardware a fraction of the power of today's mobile handsets, authenticating devices so constrained that no modern operating system would run on them (e.g. 100 Mhz PCs running Windows 3.1 with 4 MB RAM).  The devices don't even need to support cryptographic computation - RADIUS was designed to support cleartext authentication (e.g. PAP).  
In the years since RADIUS was initially deployed, we have heard complaints about insufficient support for modern cryptography, lack of features, inability to support TCP (the initial design was UDP-only), etc.  At no point have I ever heard a complaint about RADIUS being "too heavy weight".    
> I don't see a need for much in the way of profiling. Just a clear description of the problem being solved.
[BA] Amen.   RFC 2865 is already so minimal that it is hard to imagine what could be removed.  However, it would definitely be worthwhile to clarify the problem description - as it stands it is unacceptably vague.

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 16 May 2014 14:46:35 -0500

Hi Carsten,

On Thu, May 15, 2014 at 10:29 AM, Carsten Bormann <[email-masked]> wrote:

> We know that EAP/PANA can be made to work for network authentication in
> single-domain networks built out of class-2 devices.
> (And the multiple domains may be more complicated than the essentially
> just federated eduroam-style multi-domain network.)
>
Multi-domain issue can be resolved, I think. A good example is Fixed Mobile
Convergence which involves more than one operator domains and EAP is used
there, in one it is carried in RADIUS in another in Diameter.

And it works.

Regards,

Behcet

> What became pretty clear in our recent ABFAB tutorial call is that this is
> not a plug-and-play situation with the existing protocols that make ABFAB
> work.  Some development (and not just assembly) required.
>
> But the more important question really is whether the ABFAB model of
> players and roles fits with what needs to be done in a typical
> constrained-node network.  For one, NAIs are a great answer, just not
> necessarily to our questions.
>
> Grüße, Carsten
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 17 May 2014 09:50:56 -0400

Likepeng,

Sorry for the top-post.

Thank you for the definitions and better descriptions for 'resource'.
I think Paul got it right in his comment, the term resource is
well-known for REST-heads as he called them.  Is it worth having that
reference or do folks like the definitions as provided below without
that additional reference?

Some of the feedback on the charter is that it would be helpful to
have it be clearer and more concise.  The discussion has very
productive, with many angles/questions being explored.    Would it be
helpful to see what the revision looks like and to see if we are
getting closer?

Thanks!

-- 

Best regards,
Kathleen

---

From: Likepeng <[email-masked]>
Date: Sun, 18 May 2014 20:52:13 +0000

>Somewhere near the top define or reference "RESTful constrained environments", then use "RESTful constrained environments" throughout.

I notice that "Constrained RESTful Environments" is used as the group name for CoRE.

in CoAP protocol, we usually use "constrained environment".

To avoid confusion, I propose to keep the "constrained environment", but add one sentence near the top to say:
REST architecture is widely used for such constrained environments.

Kind Regards
Kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 Paul Duffy
发送时间: 2014年5月16日 0:17
收件人: [email-masked]
主题: Re: [Ace] Benoit Claise's Block on charter-ietf-ace-00-01: (with BLOCK)

Folks,

Somewhere near the top define  or reference "RESTful constrained environments", then use "RESTful constrained environments" throughout.

---

From: Likepeng <[email-masked]>
Date: Sun, 18 May 2014 20:52:39 +0000

>The Charter makes a number of assertions that are provably false, such as that AAA protocols are inappropriate for constrained environments.

In fact, the charter does not say that. But to avoid confusion, let's remove AAA protocol from the charter.

In the charter, we mentioned that we want to reuse existing authentication and authorization protocols where applicable to build the constrained-environment solution.

Thanks,
Kind Regards
Kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 Benoit Claise
发送时间: 2014年5月15日 6:12
收件人: The IESG
抄送: [email-masked]; [email-masked]
主题: [Ace] Benoit Claise's Block on charter-ietf-ace-00-01: (with BLOCK)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.

1.

...

2.

---

From: Likepeng <[email-masked]>
Date: Sun, 18 May 2014 20:52:47 +0000

Hi Kathleen and all,

>Is it worth having that reference or do folks like the definitions as provided below without that additional reference?

As far as I understand Paul's comments, if we added RESTful related clarification, people can understand the context of resources. We can certainly add a reference if it is preferred.

>Would it be helpful to see what the revision looks like and to see if we are getting closer?

I provided a new revision below. Hope we are getting closer.

Thanks,
Kind Regards
Kepeng

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Charter charter-ietf-ace-00-02
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. 
REST architecture is widely used for such constrained environments.
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 is the
authorization policy 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), 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 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 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 (GET, PUT, POST, 
DELETE) to resources identified by a URI and hosted on a resource
server 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.

Existing authentication and authorization protocols will be used where
applicable to build the constrained-environment solution. 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, in which case the solution may also involve new
protocol work. 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.

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. The working group will not work on other application 
protocols with their related transport protocols, and other protocols 
at other layers in the stack, until the work on CoAP and HTTP
with DTLS and TLS is completed. Furthermore, to guarantee smooth transition, the
integration with existing deployments will be studied, particularly
concerning the use of protocol translation proxies.

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.

Proposed Milestones 
No milestones for charter found.

-----邮件原件-----
发件人: Kathleen Moriarty [mailto:[email-masked]] 
发送时间: 2014年5月17日 21:51
收件人: Likepeng
抄送: Benoit Claise; The IESG; [email-masked]; [email-masked]
主题: Re: [Ace] Benoit Claise's Block on charter-ietf-ace-00-01: (with BLOCK)

Likepeng,

Sorry for the top-post.

Thank you for the definitions and better descriptions for 'resource'.
I think Paul got it right in his comment, the term resource is well-known for REST-heads as he called them.  Is it worth having that reference or do folks like the definitions as provided below without that additional reference?

Some of the feedback on the charter is that it would be helpful to have it be clearer and more concise.  The discussion has very
productive, with many angles/questions being explored.    Would it be
helpful to see what the revision looks like and to see if we are getting closer?

Thanks!

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 18 May 2014 23:02:14 -0400

Hi Likepeng,

I'm fine with or without it, it just depends if people find it helpful.  The term was obvious to me because of other projects using REST and my familiarity.  It's up to the group if it is helpful or not.

Thanks,
Kathleen 

Sent from my iPhone

> On May 18, 2014, at 4:52 PM, Likepeng <[email-masked]> wrote:
> 
> Hi Kathleen and all,
>

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 19 May 2014 09:51:57 +0200

On 05/16/2014 09:31 PM, Bernard Aboba wrote:
> [BA] I have run global networks with RADIUS servers based on hardware a
> fraction of the power of today's mobile handsets, authenticating devices
> so constrained that no modern operating system would run on them (e.g.
> 100 Mhz PCs running Windows 3.1 with 4 MB RAM).  The devices don't even
> need to support cryptographic computation - RADIUS was designed to
> support cleartext authentication (e.g. PAP).
>

I'd recommend that you have a look at the work of the LWIG WG
(RFC 7228). You will find that when we talk about "constrained devices" 
we mean something like 10 KB RAM and 100 KB persistent memory.
When it comes to network traffic, we struggle to keep message sizes 
under 50 bytes to avoid fragmentation at the link layer.

Do you really think that RADIUS would work for such devices without 
further adaptation?

Regards,
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: Robert Cragie <[email-masked]>
Date: Mon, 19 May 2014 09:23:28 +0100

Let's be clear here: It was never said (in the charter or anywhere else 
in the group to my knowledge) that RADIUS (or indeed any other AAA 
protocol) would not run on constrained devices (RFC 7228). The charter 
simply said the protocols were not optimised for constrained devices. 
That does not preclude considering any protocol for suitability for 
constrained devices either a) as is, b) in a restricted way or c) in an 
adapted way.

So, at this stage, I don't think any protocols should be excluded from 
consideration and should certainly not be eliminated on a hunch that 
they might be "too big". Let's do the assessment properly at the 
appropriate time. As a reminder - the focus now is to complete the charter.

Robert

On 19/05/2014 8:51 AM, Ludwig Seitz wrote:
> (RFC 7228). You will find that when we talk about "constrained 
> devices" we mean something like 10 KB RAM and 100 KB persistent memory.

---

From: Likepeng <[email-masked]>
Date: Mon, 26 May 2014 08:16:47 +0000

Hello all,

Based on recent discussions, I made a revised charter proposal, as included in this email, not on the webpage yet. 

Please take a look and let us know if you have any further comments.

@Adrian and @Benoit, please check if the proposed texts can resolve your comments.

Thanks,
Kind Regards
Kepeng

-------------------------------------------------------------------------------------------------------------------------------------------------------------
Compared with charter-ietf-ace-00-01 on the webpage, the changes are:

(1)	Add one clarification sentence about REST architecture:
OLD
The IETF has recently developed protocols for use in constrained
environments, where network nodes are limited in CPU, memory and power. 
REST architecture is widely used for such constrained environments.

NEW

(2)	Remove “AAA protocol” from the charter:
OLD
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).

NEW
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), and the Web Authorization Protocol (OAuth).
END

(3) Clarify the scope:
OLD:
Note that the initial focus is on CoAP and HTTP with DTLS and TLS.
Other security protocols may be considered as long as the primary focus is maintained.  
Other application protocols and protocols at other layers in the stack are out of scope.

NEW
Note that the initial focus is on CoAP and HTTP with DTLS and TLS.
Other security protocols may be considered as long as the primary focus is maintained.  
The group is scoped to work only on the web protocols and data carried within them.
END

(4)	Update milestones for the use case & requirements document:
OLD:
Jul 2015 Submit “Use cases and Requirements” document to IESG for publication as informational RFC.

NEW
Dec 2014 Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC.
END

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Charter charter-ietf-ace-00-02
Authentication and Authorization for Constrained
Environment (ACE)

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. Note that the initial focus is on CoAP and HTTP with DTLS and TLS.
Other security protocols may be considered as long as the primary focus is maintained.  
The group is scoped to work only on the web protocols and data carried within them.
Furthermore, to guarantee smooth transition, the
integration with existing deployments will be studied, particularly
concerning the use of protocol translation proxies.

Milestones:

Jul 2014 Submit "Use cases and Requirements" as a WG item.
Dec 2014 Submit "Authentication and Authorization Solution" as a WG item.
Dec 2014 Optionally, 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.

Proposed Milestones

---

From: Rene Struik <[email-masked]>
Date: Mon, 26 May 2014 12:57:19 -0400

Hi Kepeng:

I just read your suggested changes. As to #1, it seems that that the old 
text and the new text are the same. With #2, I am not sure what the 
effect of simply removing the AAA reference on chartering objections 
could be (after all, the third para simply mentions some context [IETF 
apparently having a rich tradition [for whatever that is worth] with 
developing three-party protocols).

I would suggest three changes to the 00-01 draft charter, which I 
believe would help in removing block positions (essentially limiting 
scope of current charter, removing impression of already drawn 
conclusions prior to start of work):

#RS-1: remove any suggestion that existing solutions are already known 
to be suitable (this is still to be seen and part of the work of this 
group). This removes the current tension between para 4 and para 6, 
where para 4 says "indicate the suitability of existing work", whereas 
para 6 suggests "this requires relevant specifications to be reviewed 
for suitability". This is why I raised as concern in my original draft 
review of April 10, 2014, 5:58pm EDT 
(http://www.ietf.org/mail-archive/web/ace/current/msg00517.html) that 
one should engage into this effort with open mind, without presorting 
solution directions in the charter.

OLD:

work as a solution for constrained environments

NEW:

Requirements derived from use cases may indicate that existingwork is 
useful as basis for as a solution for constrained environments

#RS-2:  I would suggest scrapping the entire para 7, since much too 
ambitious (one can easily recharter to take on more work or refocus at a 
later stage). I made the same comment on the original draft charter 
(April 10, 2014, 5:59pm EDT).

OLD:

will be investigated. Note that the work is limited to CoAP and HTTP

with DTLS and TLS. Other application protocols with their related

are out of scope. Furthermore, to guarantee smooth transition, the

NEW:

The working group will focus on CoAP and DTLS for access to resources. 
Any other work will require rechartering.

#RS-3: I would suggest taking more time for the use cases and 
requirements than currently suggested. Given the lengthy discussion on 
draft charter and ACE WG coming into operation potentially just prior to 
the July 2014 IETF meeting, I would suggest being more reflective on use 
cases and aiming for WG item here after November 2014 meeting (Dec 2014) 
and IESG phase Apr 2015. Not much harm will be done here, since solution 
and use cases can be co-developed in parallel and, moreover, one can 
always strive for beating the schedule (overdelivering, so to speak).

OLD:

Dec 2014 Submit Optionally submit "Use cases and Requirements" document 
to the IESG for

NEW:

Dec 2014 Submit "Use cases and Requirements" as a WG item.

Apr 2015 Submit Optionally submit "Use cases and Requirements" document 
to the IESG for

Best regards, Rene

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

---

From: Likepeng <[email-masked]>
Date: Mon, 26 May 2014 20:16:51 +0000

Hi Rene,
>As to #1, it seems that that the old text and the new text are the same.
Sorry, it should be like this:

OLD

NEW

END

>#RS-2:  I would suggest scrapping the entire para 7, since much too ambitious (one can easily recharter to take on more work or refocus at a later stage). I made the same comment on the original draft charter (April 10, 2014, 5:59pm EDT).

>The working group will focus on CoAP and DTLS for access to resources. Any other work will require re-chartering.

This was what we started from the beginning. In London BoF, there was no consensus about this scope. Some people want to support HTTP / TLS, also recent discussions indicate the needs for data object security.

For your change proposal #1 and #3, let’s see other’s opinion.

Thanks,
Kind Regards
Kepeng
发件人: Rene Struik [mailto:[email-masked]]
发送时间: 2014年5月27日 0:57
收件人: Likepeng; Kathleen Moriarty; [email-masked]
抄送: Benoit Claise; [email-masked]; The IESG; [email-masked]
主题: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02

Hi Kepeng:

I just read your suggested changes. As to #1, it seems that that the old text and the new text are the same. With #2, I am not sure what the effect of simply removing the AAA reference on chartering objections could be (after all, the third para simply mentions some context [IETF apparently having a rich tradition [for whatever that is worth] with developing three-party protocols).

I would suggest three changes to the 00-01 draft charter, which I believe would help in removing block positions (essentially limiting scope of current charter, removing impression of already drawn conclusions prior to start of work):

#RS-1: remove any suggestion that existing solutions are already known to be suitable (this is still to be seen and part of the work of this group). This removes the current tension between para 4 and para 6, where para 4 says "indicate the suitability of existing work", whereas para 6 suggests "this requires relevant specifications to be reviewed for suitability". This is why I raised as concern in my original draft review of April 10, 2014, 5:58pm EDT (http://www.ietf.org/mail-archive/web/ace/current/msg00517.html) that one should engage into this effort with open mind, without presorting solution directions in the charter.

OLD:

NEW:
Requirements derived from use cases may indicate that existing work is useful as basis for as a solution for constrained environments

#RS-2:  I would suggest scrapping the entire para 7, since much too ambitious (one can easily recharter to take on more work or refocus at a later stage). I made the same comment on the original draft charter (April 10, 2014, 5:59pm EDT).

OLD:

NEW:
The working group will focus on CoAP and DTLS for access to resources. Any other work will require rechartering.

#RS-3: I would suggest taking more time for the use cases and requirements than currently suggested. Given the lengthy discussion on draft charter and ACE WG coming into operation potentially just prior to the July 2014 IETF meeting, I would suggest being more reflective on use cases and aiming for WG item here after November 2014 meeting (Dec 2014) and IESG phase Apr 2015. Not much harm will be done here, since solution and use cases can be co-developed in parallel and, moreover, one can always strive for beating the schedule (overdelivering, so to speak).

OLD:

Jul 2014 Submit "Use cases and Requirements" as a WG item.
Dec 2014 Submit Optionally submit "Use cases and Requirements" document to the IESG for
publication as an Informational RFC.

NEW:

Dec 2014 Submit "Use cases and Requirements" as a WG item.
Apr 2015 Submit Optionally submit "Use cases and Requirements" document to the IESG for
publication as an Informational RFC.

Best regards, Rene

Hello all,

Thanks,

Kind Regards

Kepeng

OLD

NEW

END

OLD

NEW

END

(3) Clarify the scope:

OLD:

NEW

END

OLD:

NEW

END

Environment (ACE)

constrained.

constrained.

access services.

Milestones:

Proposed Milestones

Ace mailing list

[email-masked]<mailto:[email-masked]>

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 29 May 2014 17:54:34 +0200

Hi everyone,

> useful as basis for as a solution for constrained environments

I think we can benefit from carefully reviewing existing protocols for
their applicability to constrained environments. If we come to the
conclusion that one of the proposed solutions is fitting, this is a good
result. And we might have a clue afterwards which one of them fits best.
The expectation is that some requirements of constrained environments
can not easily be met by existing solutions and we might need to define
profiles or extensions or otherwise bridge the gaps. We should be open
for ideas and not try to fit a round piece through a square hole because
it might work somehow.

The need for an authentication and authorization solution for
constrained environments came up in the CoRE working group. The reason
for initiating the ACE working group is that the discussions about
possible solutions took up so much time in CoRE that other topics of the
group were delayed.

> Any other work will require rechartering.

Concerning #RS-2: As I mentioned before I would be happy to leave
speculations about future work after rechartering out of the charter.

> Jul 2014 Submit "Use cases and Requirements"� as a WG item.
> 
> Dec 2014 Submit "Use cases and Requirements"� as a WG item.
> 

#RS-3: The discussion about the Use cases and Requirements draft
indicated that it would be beneficial to work on this draft in parallel
while working on the solution. This is only possible if we set the
milestone accordingly.

Best regards,
Steffi

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 29 May 2014 19:48:39 +0200

Maybe the purpose of my previous note was not clear enough. My intent
was to reason why I support Renes proposed changes to the charter.

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