Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Dan Garcia]

Hi Benjamin,

Thank you for your suggestion. Your comment is relevant.

In fact, we wrote some time ago an article regarding our initial design, 
and we perform a comparison with other network layer based EAP 
lower-layer (https://www.mdpi.com/1424-8220/16/3/358)


We compared focusing EAP lower-layer (alone) and taking into account 
EAP. On the one hand, at EAP lower-layer level, the usage of CoAP gives 
us an important benefits. On the other hand, when taking into account 
the EAP method overload, this reduction is less but still significant if 
the EAP method is lightweight (we used EAP-PSK as a representative 
example of a lightweight EAP method). As you suggest, if the EAP method 
is very taxing (as the case you mentioned) the improvement carried out 
in the EAP lower-layer is less significant. This leads to the conclusion 
that possible next steps in this field could be also improving or 
designing new EAP methods that can be better adapted to the requirements 
of constrained devices and networks. However, we cannot ignore the 
impact of the EAP lower-layer itself and try to propose something light 
as we do proposing CoAP.


We consider that may be others EAP methods such as EAP-AKA or new 
lightweight EAP methods such as EAP-EDHOC 
(https://tools.ietf.org/html/draft-ingles-eap-edhoc-01) that can benefit 
from a CoAP-based EAP lower-layer, as well as new ones that may be 
proposed in the future with IoT constraints in mind.


Best Regards,
Dan.

El 12/1/21 a las 20:05, Benjamin Kaduk escribió:

Hi Dan,

Sorry to reply to such an old message...

On Sat, Dec 12, 2020 at 06:36:53PM +0100, Dan Garcia Carrillo wrote:

Hi Mališa,


El 11/12/2020 a las 19:45, Mališa Vučinić escribió:

Hi Dan,

Thanks for the clarification regarding minimal-security. The points
that you mention below, e.g. flexible authentication or the fresh
generation of the PSK, were never in the design scope of our work.

While I fail to understand what exactly do you plan on using
EAP-over-CoAP for, I do not object on this work being done in ACE if
you are willing to spend cycles on it. I do have reservations on the
lightweight aspect of this, however, considering that the sequence
diagram that you depict in Fig. 2 in draft-marin-ace-wg-coap-eap-06
spans 3 pages and consumes 2 round trips just to get things started!
Surely, we can do better?


Yes, we will submit an updated version of the draft.

When you do, I suggest putting in some discussion of the relative
size/overhead for CoAP as EAP lower-layer vs the EAP payloads themselves.
I note that the IESG recently approved draft-ietf-emu-eaptlscert that
discusses some pathological cases with TLS-based EAP methods and very large
certificate chains.  While I assume that you're not planning to do
EAP-over-CoAP with such long TLS certificate chains, giving reviewers a
sense for how big of an improvement this mechanism can be will presumably
be helpful.

Thanks,

Ben


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Benjamin Kaduk]

Hi Dan,

Sorry to reply to such an old message...

On Sat, Dec 12, 2020 at 06:36:53PM +0100, Dan Garcia Carrillo wrote:
> Hi Mališa,
> 
> 
> El 11/12/2020 a las 19:45, Mališa Vučinić escribió:
> >
> > Hi Dan,
> >
> > Thanks for the clarification regarding minimal-security. The points 
> > that you mention below, e.g. flexible authentication or the fresh 
> > generation of the PSK, were never in the design scope of our work.
> >
> > While I fail to understand what exactly do you plan on using 
> > EAP-over-CoAP for, I do not object on this work being done in ACE if 
> > you are willing to spend cycles on it. I do have reservations on the 
> > lightweight aspect of this, however, considering that the sequence 
> > diagram that you depict in Fig. 2 in draft-marin-ace-wg-coap-eap-06 
> > spans 3 pages and consumes 2 round trips just to get things started! 
> > Surely, we can do better?
> >
> Yes, we will submit an updated version of the draft.

When you do, I suggest putting in some discussion of the relative
size/overhead for CoAP as EAP lower-layer vs the EAP payloads themselves.
I note that the IESG recently approved draft-ietf-emu-eaptlscert that
discusses some pathological cases with TLS-based EAP methods and very large
certificate chains.  While I assume that you're not planning to do
EAP-over-CoAP with such long TLS certificate chains, giving reviewers a
sense for how big of an improvement this mechanism can be will presumably
be helpful.

Thanks,

Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Dan Garcia Carrillo]

Hi Mališa,


El 11/12/2020 a las 19:45, Mališa Vučinić escribió:


Hi Dan,

Thanks for the clarification regarding minimal-security. The points 
that you mention below, e.g. flexible authentication or the fresh 
generation of the PSK, were never in the design scope of our work.


While I fail to understand what exactly do you plan on using 
EAP-over-CoAP for, I do not object on this work being done in ACE if 
you are willing to spend cycles on it. I do have reservations on the 
lightweight aspect of this, however, considering that the sequence 
diagram that you depict in Fig. 2 in draft-marin-ace-wg-coap-eap-06 
spans 3 pages and consumes 2 round trips just to get things started! 
Surely, we can do better?



Yes, we will submit an updated version of the draft.

Best Regards,

Dan


Mališa

*From: *Dan Garcia Carrillo 
*Date: *Friday 11 December 2020 at 18:41
*To: *Mališa Vučinić , Michael Richardson 
, EMU WG , "c...@ietf.org WG 
(c...@ietf.org)" , "ace@ietf.org" 

*Cc: *
*Subject: *Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

Hi Mališa,

My intention was not to turn this conversation into a criticism of 
your work. “deficiencies” was not the most appropriate word.


What we had in mind was a way of providing authentication  to the 
variety of IoT devices with different capabilities, limitations or 
different types of supported credentials. A way of doing that is to 
provide different authentication methods. Since in IoT there are 
different technologies we looked for a link-layer independent 
solution. Additionally, since some technologies are very constrained, 
we needed a very constrained protocol to carry out the process.


EAP provides flexible authentication, and it has EAP Key Management 
Framework which is well specified and working for many years, from 
which you can generate generate a fresh pre-shared key (MSK) 
dynamically. This is even possible if you do not want to interact with 
AAA infrastructures running EAP in standalone mode.  Having said this, 
another thing that we looked into was to give support to large scale 
deployments. We can ease this process with EAP and its interaction 
with a AAA infrastructure, which gains relevance in Industrial IoT and 
5G.


All these characteristics can be provided by the use of EAP, if we of 
course have a lightweight EAP lower layer to transport EAP from the 
IoT device. Then we considered the usage of CoAP as EAP lower-layer.


In this sense, we saw minimal security did not fit our view (no 
potential interaction with AAA , flexible authentication, fresh 
generation of PSK).  In fact,  the provisioning of the PSK was out of 
scope.


At some level, we could even consider the work complementary. EAP over 
CoAP could be a way of providing the PSK for the work of minimal 
security.



Best Regards,
Dan.

El 10/12/2020 a las 18:43, Mališa Vučinić escribió:

Hi Dan,

Could you be more specific on the point below, what deficiencies
do you have in mind?

Mališa

*From: *core 
<mailto:core-boun...@ietf.org> on behalf of Dan Garcia
 <mailto:garcia...@uniovi.es>
*Date: *Thursday 10 December 2020 at 10:06
*To: *Michael Richardson 
<mailto:mcr+i...@sandelman.ca>, EMU WG 
<mailto:e...@ietf.org>, "c...@ietf.org WG (c...@ietf.org)"
<mailto:core@ietf.orgWG(c...@ietf.org)> 
<mailto:c...@ietf.org>, "ace@ietf.org" <mailto:ace@ietf.org>
     <mailto:ace@ietf.org>
*Subject: *Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

As you comment , draft-ietf-6tisch-minimal-security - offers
minimal security and has several deficiencies that can be solved
by using EAP and AAA infrastructures.

-->

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Mališa Vučinić]

Hi Dan,

 

Thanks for the clarification regarding minimal-security. The points that you 
mention below, e.g. flexible authentication or the fresh generation of the PSK, 
were never in the design scope of our work. 

 

While I fail to understand what exactly do you plan on using EAP-over-CoAP for, 
I do not object on this work being done in ACE if you are willing to spend 
cycles on it. I do have reservations on the lightweight aspect of this, 
however, considering that the sequence diagram that you depict in Fig. 2 in 
draft-marin-ace-wg-coap-eap-06 spans 3 pages and consumes 2 round trips just to 
get things started! Surely, we can do better?

 

Mališa

 

From: Dan Garcia Carrillo 
Date: Friday 11 December 2020 at 18:41
To: Mališa Vučinić , Michael Richardson 
, EMU WG , "c...@ietf.org WG 
(c...@ietf.org)" , "ace@ietf.org" 
Cc: 
Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

 

Hi Mališa, 

My intention was not to turn this conversation into a criticism of your work. 
“deficiencies” was not the most appropriate word.

What we had in mind was a way of providing authentication  to the variety of 
IoT devices with different capabilities, limitations or different types of 
supported credentials. A way of doing that is to provide different 
authentication methods. Since in IoT there are different technologies we looked 
for a link-layer independent solution. Additionally, since some technologies 
are very constrained, we needed a very constrained protocol to carry out the 
process.

EAP provides flexible authentication, and it has EAP Key Management Framework 
which is well specified and working for many years, from which you can generate 
generate a fresh pre-shared key (MSK) dynamically. This is even possible if you 
do not want to interact with AAA infrastructures running EAP in standalone 
mode.  Having said this, another thing that we looked into was to give support 
to large scale deployments. We can ease this process with EAP and its 
interaction with a AAA infrastructure, which gains relevance in Industrial IoT 
and 5G. 

All these characteristics can be provided by the use of EAP, if we of course 
have a lightweight EAP lower layer to transport EAP from the IoT device. Then 
we considered the usage of CoAP as EAP lower-layer.

In this sense, we saw minimal security did not fit our view (no potential 
interaction with AAA , flexible authentication, fresh generation of PSK).  In 
fact,  the provisioning of the PSK was out of scope. 

At some level, we could even consider the work complementary. EAP over CoAP 
could be a way of providing the PSK for the work of minimal security. 


Best Regards,
Dan.

El 10/12/2020 a las 18:43, Mališa Vučinić escribió:

Hi Dan,

 

Could you be more specific on the point below, what deficiencies do you have in 
mind?

 

Mališa 

 

From: core  on behalf of Dan Garcia 
Date: Thursday 10 December 2020 at 10:06
To: Michael Richardson , EMU WG , 
"c...@ietf.org WG (c...@ietf.org)" , "ace@ietf.org" 

Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

 

As you comment , draft-ietf-6tisch-minimal-security - offers minimal security 
and has several deficiencies that can be solved by using EAP and AAA 
infrastructures. 

-->

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Dan Garcia Carrillo]

Hi Mališa,

My intention was not to turn this conversation into a criticism of your 
work. “deficiencies” was not the most appropriate word.


What we had in mind was a way of providing authentication  to the 
variety of IoT devices with different capabilities, limitations or 
different types of supported credentials. A way of doing that is to 
provide different authentication methods. Since in IoT there are 
different technologies we looked for a link-layer independent solution. 
Additionally, since some technologies are very constrained, we needed a 
very constrained protocol to carry out the process.


EAP provides flexible authentication, and it has EAP Key Management 
Framework which is well specified and working for many years, from which 
you can generate generate a fresh pre-shared key (MSK) dynamically. This 
is even possible if you do not want to interact with AAA infrastructures 
running EAP in standalone mode. Having said this, another thing that we 
looked into was to give support to large scale deployments. We can ease 
this process with EAP and its interaction with a AAA infrastructure, 
which gains relevance in Industrial IoT and 5G.


All these characteristics can be provided by the use of EAP, if we of 
course have a lightweight EAP lower layer to transport EAP from the IoT 
device. Then we considered the usage of CoAP as EAP lower-layer.


In this sense, we saw minimal security did not fit our view (no 
potential interaction with AAA , flexible authentication, fresh 
generation of PSK).  In fact,  the provisioning of the PSK was out of 
scope.


At some level, we could even consider the work complementary. EAP over 
CoAP could be a way of providing the PSK for the work of minimal security.



Best Regards,
Dan.

El 10/12/2020 a las 18:43, Mališa Vučinić escribió:


Hi Dan,

Could you be more specific on the point below, what deficiencies do 
you have in mind?


Mališa

*From: *core  on behalf of Dan Garcia 


*Date: *Thursday 10 December 2020 at 10:06
*To: *Michael Richardson , EMU WG 
, "c...@ietf.org WG (c...@ietf.org)" , 
"ace@ietf.org" 

*Subject: *Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

As you comment , draft-ietf-6tisch-minimal-security - offers minimal 
security and has several deficiencies that can be solved by using EAP 
and AAA infrastructures.


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Mališa Vučinić]

Hi Dan,

 

Could you be more specific on the point below, what deficiencies do you have in 
mind?

 

Mališa 

 

From: core  on behalf of Dan Garcia 
Date: Thursday 10 December 2020 at 10:06
To: Michael Richardson , EMU WG , 
"c...@ietf.org WG (c...@ietf.org)" , "ace@ietf.org" 

Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

 

As you comment , draft-ietf-6tisch-minimal-security - offers minimal security 
and has several deficiencies that can be solved by using EAP and AAA 
infrastructures. 

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Dan Garcia]

 Hi Michael,


"/1) .../"

For onboarding a new device, where there is no connectivity after 
authentication, you propose to use 802.1X, which is an EAP lower layer. 
EAP over CoAP is in fact a proposal for a application level EAP lower 
layer that overcomes the limitation that 802.1X works on an inferior 
layer, hence, giving the possibility to perform the network 
authentication through nodes.


This idea is not new, in fact, you have PANA, another EAP lower layer 
that works on top of UDP.


As you comment , draft-ietf-6tisch-minimal-security - offers minimal 
security and has several deficiencies that can be solved by using EAP 
and AAA infrastructures.


Regarding your second point

"/2) If it for application authentication, then you need to use EAP to 
setup MSK for later use by a context. We do this in IKEv2, (D)TLS already./"


Our proposal is to define an EAP lower layer that is specifically 
designed for constrained devices and networks. The setup of the MSK for 
later use, is what the EAP KMF does, and  this key material is used to 
run a security association protocol, that could be DTLS or OSCORE.  That 
is why it is not an afterthought as you say. I wrote could, because is 
one of the possibilities. That is another benefit of using EAP.


With respect to do this with IKEv2, EAP already has an EAP method for 
IKE. Why limit the options when EAP gives you more. What will you do if 
the specific network does not support running IKEv2 due to severe 
constrains in the network or any other reason?


That is why I believe the flexibility EAP gives you is worth considering.

Best Regards,
Dan.



On 9/12/20 19:55, Michael Richardson wrote:

Dan Garcia  wrote:
 > EAP can be used in the context of IoT for authentication.

But, to what end?

1) If it is onboarding a new device, then there is no connectivity until after 
authentication.
so you can't use CoAP, you have to use 802.1x, or some equivalent, or
create a system such as draft-ietf-6tisch-minimal-security.
Which does use CoAP and OSCORE already.

2) If it for application authentication, then you need to use EAP to setup
MSK for later use by a context.
We do this in IKEv2, (D)TLS already.

So the only left would be OSCORE, yet you write "could", as if it was an 
afterthought.

Tell me what is your application?  What will be impossible if we don't do
this work?

--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide




___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Michael Richardson]

Dan Garcia  wrote:
> EAP can be used in the context of IoT for authentication.

But, to what end?

1) If it is onboarding a new device, then there is no connectivity until after 
authentication.
   so you can't use CoAP, you have to use 802.1x, or some equivalent, or
   create a system such as draft-ietf-6tisch-minimal-security.
   Which does use CoAP and OSCORE already.

2) If it for application authentication, then you need to use EAP to setup
   MSK for later use by a context.
   We do this in IKEv2, (D)TLS already.

So the only left would be OSCORE, yet you write "could", as if it was an 
afterthought.

Tell me what is your application?  What will be impossible if we don't do
this work?

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Carsten Bormann]

On 2020-12-09, at 14:28, Christian Amsüss  wrote:
>
> follow CoRE best practices

Indeed; for instance, we “RESTified” documents in ACE before (and they not just 
became ideologically correct, but also plain better).

Grüße, Carsten



signature.asc
Description: Message signed with OpenPGP
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Alexander Pelov]

Dear all,

I support the inclusion of EAP-over-CoAP to the charter.

We've done work on this particular item in the past, and we've identified
the need for it in many places.. but unfortunately the draft didn't have a
proper "home" and things never advanced much. Use-cases we've seen include
places where EAP is a MUST, there is support for CoAP, but no support for
the specific FOO technology.

I am confident that it will bring value to the IOT ecosystem and that ACE
is the right home for this draft.

Cheers,
Alexander


On Wed, Dec 9, 2020 at 12:46 PM Dan Garcia  wrote:

>  Hi Michael,
>
> EAP can be used in the context of IoT for authentication. To transport EAP
> from the IoT device we need a light EAP lower-layer. This would be CoAP.
> Morover, according to EAP key management framework, keys are exported to
> protect the link and the EAP lower-layer itself. So yes, OSCORE could be
> used for that kind of protection.
>
>  Another aspect, it is that the use case we consider is the case where an
> IoT device is trying to access a security domain under the control of a
> “controller” that is connected to a backend AAA infrastructure, which acts
> as EAP authenticator.
>
>  Best Regards.
> El 07/12/2020 a las 23:09, Michael Richardson escribió:
>
> Could someone point to a use case for "EAP over CoAP" please?
> Is the goal to key an OSCORE context, or what?
>
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
>
>
>
> ___
> Ace mailing listAce@ietf.orghttps://www.ietf.org/mailman/listinfo/ace
>
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Dan Garcia]

 Hi Michael,

EAP can be used in the context of IoT for authentication. To transport 
EAP from the IoT device we need a light EAP lower-layer. This would be 
CoAP. Morover, according to EAP key management framework, keys are 
exported to protect the link and the EAP lower-layer itself. So yes, 
OSCORE could be used for that kind of protection.


 Another aspect, it is that the use case we consider is the case where 
an IoT device is trying to access a security domain under the control of 
a “controller” that is connected to a backend AAA infrastructure, which 
acts as EAP authenticator.


 Best Regards.

El 07/12/2020 a las 23:09, Michael Richardson escribió:

Could someone point to a use case for "EAP over CoAP" please?
Is the goal to key an OSCORE context, or what?

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Michael Richardson]

Could someone point to a use case for "EAP over CoAP" please?
Is the goal to key an OSCORE context, or what?

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Göran Selander]

+1.

(The recently updated ACE charter should cover this work.)

Göran

On 2020-12-03, 20:03, "core"  wrote:
Hi,
I think it is important to have EAP on top of CoAP, as Dan said it fit well 
with the last charter item.

Laurent


On Thu, Dec 3, 2020 at 2:20 PM Daniel Migault 
mailto:daniel.migault=40ericsson@dmarc.ietf.org>>
 wrote:


CCing emu, core

It seems ACE to me that ACE could be home for such a document. I am wondering 
if emu core or any other WG believe there is a better place for it.

Regarding ACE I am wondering what is the WG opinion about adding this item to 
the ACE charter.

Yours,
Daniel

From: Ace mailto:ace-boun...@ietf.org>> on behalf of Dan 
Garcia mailto:dan.gar...@um.es>>
Sent: Thursday, December 3, 2020 6:10 AM
To: ace@ietf.org mailto:ace@ietf.org>>
Subject: [Ace] Proposed charter for ACE (EAP over CoAP?)

Dear all:

Regarding the new charter, since ACE is considering the definition of CoAP 
transport for CMPv2 
(https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00), we were 
wondering whethere it could also consider specifying EAP (Extensible 
Authentication Protocol) over CoAP.

In this sense, we proposed this some time ago and we have implementations about 
this.

https://datatracker.ietf.org/doc/html/draft-marin-ace-wg-coap-eap-06
https://www.mdpi.com/1424-8220/16/3/358
https://www.mdpi.com/1424-8220/17/11/2646

The usage of CoAP can provide a very light and link-layer independent (we even 
tested in LoRa networks) EAP lower-layer (transport for EAP) suitable for IoT 
enviroment. We believe this would be really useful since EAP provides 
flexibility for the authentication and it is a well-known protocol.

Therefore, we would like to propose the following modification to the charter:

"The Working Group will examine how to use Constrained Application Protocol 
(CoAP) as a transport medium for certificate enrollment protocols, such as EST 
and CMPv2, as well as a transport for authentication protocols such as EAP, and 
standardize them as needed."

This modification does not necessarily mean the adoption of our draft. After 
all, we completely understand that this would happen only if there is an 
interest in the WG. Nevertheless, we would like to avoid that the charter is a 
barrier later if there is interest in the WG to work in this transport of EAP 
over CoAP:

Any opinion about this?

Best Regards.

El 18/11/2020 a las 8:08, Daniel Migault escribió:


Hi,
Please find the proposed charter we agreed on during the interim meeting. If 
you would like to propose any change, please use the following URL by November 
25:

https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing
 



Yours,
Daniel

The Authentication and Authorization for Constrained Environments (ace) WG has 
defined a standardized solution framework for authentication and authorization 
to enable authorized access to resources identified by a URI and hosted on a 
resource server in constrained environments.
The access to the resource is mediated by an authorization server, which is not 
considered to be constrained.

Profiles of this framework for application to security protocols commonly used 
in constrained environments, including CoAP+DTLS and CoAP+OSCORE, have also 
been standardized.  The Working Group is charged with maintenance of the 
framework and existing profiles thereof, and may undertake work to specify 
profiles of the framework for additional secure communications protocols and 
for additional support services providing authorized access to crypto keys 
(that are not necessarily limited to constrained endpoints, though the focus 
remains on deployment in ecosystems with a substantial portion of constrained 
devices).

In addition to the ongoing maintenance work, the Working Group will extend the 
framework as needed for applicability to group communications, with initial 
focus on (D)TLS and (Group) OSCORE as the underlying group communication 
security protocols. The Working Group will standardize procedures for 
requesting and distributing group keying material using the ACE framework as 
well as appropriated management interfaces.

The Working Group will standardize a format for expressing authorization 
information for a given authenticated principal as received from an 
authorization manager.

The Working Group will examine how to use Constrained Application Protocol 
(CoAP) as a transport medium for certificate enrollment protocols, such as EST 
and CMPv2, and standardize as needed.




On Tue, Nov 17, 2020 at 6:47 PM Benjamin Kaduk 
mailto:ka...@mit.edu>> wrote:


Thanks for updating the draft charter at [1], Daniel!

I note