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

From: Dan Garcia <[email-masked]>
Date: Thu, 3 Dec 2020 12:10:11 +0100

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 
> <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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Thanks for updating the draft charter at [1], Daniel!
>
>     I note that Michael raised the question of whether some other
>     group might
>     also be interested in working on CMP-over-coap, so the IESG will
>     be sure to
>     discuss that if CMP is still in the draft ACE charter when it goes
>     to the
>     IESG for review.
>
>     -Ben
>
>     On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote:
>     > Thank you all for the feed backs. For the purpose of driving the
>     charter
>     > discussion at the IETf 109, I have added the comments into the
>     proposed
>     > text [1].
>     >
>     > My current understanding is that it seems beneficial to add
>     CMPv2 over CoAP
>     > in the charter. I am happy to be contradicted.
>     > * I have not seen a clear cut to do one or the other.
>     > * EST and CMPv2 are two protocols that can be used for
>     enrollment or cert
>     > management while addressing different cases / needs / situations
>     -- maybe
>     > we can clarify that point. I can see leveraging the existing CMP
>     > infrastructure, but it seems that is not the only one.
>     > * I am not convinced that not having CMP over CoAP will not
>     prevent its
>     > deployment and as such I prefer to have it standardized - this
>     might be a
>     > personal thought.
>     > * Adding any piece of work require cycles, but it seems to me
>     that CPM will
>     > not have a major impact on the WG progress. The work will
>     probably include
>     > other WG such a LAMPS.
>     >
>     > Yours,
>     > Daniel
>     >
>     > [1]
>     >
>     https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing
>     <https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing>
>     >
>     > On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     > > Hi Goran,
>     > >
>     > > I added the text to the charter we will discuss later.
>     > >
>     > > Yours,
>     > > Daniel
>     > >
>     > > On Fri, Nov 13, 2020 at 10:26 AM Göran Selander <
>     > > [email-masked]
>     <mailto:[email-masked]>> wrote:
>     > >
>     > >> Hi Daniel,
>     > >>
>     > >>
>     > >>
>     > >> Here’s another input to the charter.
>     > >>
>     > >>
>     > >>
>     > >> The current group key management solutions addresses the
>     problem of
>     > >> authorized access to group keys and public keys of group members.
>     > >>
>     > >>
>     > >>
>     > >> A related problem is authorized access of public keys of
>     other devices
>     > >> not necessarily part of a security group, in the sense of
>     sharing a
>     > >> symmetric key used to protect group messages.
>     > >>
>     > >>
>     > >>
>     > >> Authorized access to raw public keys serves an important
>     function in
>     > >> constrained settings where public key certificates may not be
>     feasible due
>     > >> to the incurred overhead, e.g. for when authenticating using
>     EDHOC
>     > >> (draft-ietf-lake-edhoc).
>     > >>
>     > >> This functionality is thus a subset of what is already
>     supported, but
>     > >> since the current solution is geared towards groups a
>     different solution
>     > >> may be needed (although it is probably possible to reuse
>     parts from the
>     > >> existing schemes for provisioning and requesting public keys).
>     > >>
>     > >>
>     > >>
>     > >> With this in mind, I propose the following change (highlighted in
>     > >> boldface below):
>     > >>
>     > >>
>     > >>
>     > >> OLD
>     > >>
>     > >> 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
>     (that are not
>     > >> necessarily limited to constrained endpoints, though the
>     focus remains on
>     > >> deployment ecosystems with a substantial portion of
>     constrained devices).
>     > >>
>     > >>
>     > >>
>     > >> NEW
>     > >>
>     > >> 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 ecosystems with a substantial
>     portion of
>     > >> constrained devices).
>     > >>
>     > >>
>     > >>
>     > >> Göran
>     > >>
>     > >>
>     > >>
>     > >>
>     > >>
>     > >>
>     > >>
>     > >> On 2020-10-15, 19:50, "Ace" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > >>
>     > >> Hi,
>     > >>
>     > >> I would like to start the charter discussion. Here is a draft
>     of a
>     > >> proposed charter [1].
>     > >>
>     > >>
>     > >>
>     > >> It seems to be that additional discussion is needed with
>     regard to the
>     > >> last paragraph related certificate management. In particular
>     the discussion
>     > >> might revive a discussion that happened in 2017 [2] - when I
>     was not
>     > >> co-chair of ACE -and considered other expired work such as
>     [3]. Please make
>     > >> this discussion constructive on this thread.
>     > >>
>     > >>
>     > >>
>     > >> The fundamental question is whether we need certificate
>     management at
>     > >> this stage. If the answer is yes, and we have multiple
>     proposals, it would
>     > >> be good to clarify the position of the different proposals
>     and evaluate
>     > >> whether a selection is needed or not before validating the
>     charter.
>     > >>
>     > >>
>     > >>
>     > >> Please provide your inputs on the mailing list before October
>     30. Of
>     > >> course for minor edits, you may suggest them directly on the
>     google doc.
>     > >>
>     > >>
>     > >>
>     > >> Yours,
>     > >>
>     > >> Daniel
>     > >>
>     > >>
>     > >>
>     > >> [1]
>     > >>
>     https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing
>     <https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing>
>     > >> <
>     > >>
>     https://protect2.fireeye.com/v1/url?k=4f3d9c3b-118c475b-4f3ddca0-86e2237f51fb-627e48b069462d70&q=1&e=6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing
>     <https://protect2.fireeye.com/v1/url?k=4f3d9c3b-118c475b-4f3ddca0-86e2237f51fb-627e48b069462d70&q=1&e=6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>>
>     > >>
>     > >>
>     > >> [2]
>     > >>
>     https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/
>     <https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/>
>     > >>
>     > >> [3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/
>     <https://datatracker.ietf.org/doc/draft-selander-ace-eals/>
>     > >>
>     > >>
>     > >>
>     > >> --
>     > >>
>     > >> Daniel Migault
>     > >>
>     > >>
>     > >>
>     > >> Ericsson
>     > >>
>     > >
>     > >
>     > > --
>     > > Daniel Migault
>     > > Ericsson
>     > >
>     >
>     >
>     > --
>     > Daniel Migault
>     > Ericsson
>
>     > _______________________________________________
>     > Ace mailing list
>     > [email-masked] <mailto:[email-masked]>
>     > https://www.ietf.org/mailman/listinfo/ace
>     <https://www.ietf.org/mailman/listinfo/ace>
>
>     _______________________________________________
>     Ace mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/ace
>     <https://www.ietf.org/mailman/listinfo/ace>
>
>
>
> -- 
> Daniel Migault
> Ericsson
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Daniel Migault <[email-masked]>
Date: Thu, 3 Dec 2020 13:20:08 +0000

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 <[email-masked]> on behalf of Dan Garcia <[email-masked]>
Sent: Thursday, December 3, 2020 6:10 AM
To: [email-masked] <[email-masked]>
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.

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.

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<https://protect2.fireeye.com/v1/url?k=f9dc6551-a6475d83-f9dc25ca-866132fe445e-9c25a5c257a23470&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>

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 <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for updating the draft charter at [1], Daniel!

I note that Michael raised the question of whether some other group might
also be interested in working on CMP-over-coap, so the IESG will be sure to
discuss that if CMP is still in the draft ACE charter when it goes to the
IESG for review.

-Ben

On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote:
> Thank you all for the feed backs. For the purpose of driving the charter
> discussion at the IETf 109, I have added the comments into the proposed
> text [1].
>
> My current understanding is that it seems beneficial to add CMPv2 over CoAP
> * EST and CMPv2 are two protocols that can be used for enrollment or cert
> management while addressing different cases / needs / situations -- maybe
> * I am not convinced that not having CMP over CoAP will not prevent its
> deployment and as such I prefer to have it standardized - this might be a
> personal thought.
> * Adding any piece of work require cycles, but it seems to me that CPM will
> not have a major impact on the WG progress. The work will probably include
> other WG such a LAMPS.
>
> Yours,
> Daniel
>
> [1]
> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing<https://protect2.fireeye.com/v1/url?k=a01e017d-ff8539af-a01e41e6-866132fe445e-7268e18ca0e30ad7&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
>
> On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:
>
> > Hi Goran,
> >
> > [email-masked]<mailto:[email-masked]>> wrote:
> >
> >> Hi Daniel,
> >>
> >>
> >>
> >> The current group key management solutions addresses the problem of
> >> A related problem is authorized access of public keys of other devices
> >> not necessarily part of a security group, in the sense of sharing a
> >> Authorized access to raw public keys serves an important function in
> >> constrained settings where public key certificates may not be feasible due
> >> to the incurred overhead, e.g. for when authenticating using EDHOC
> >> (draft-ietf-lake-edhoc).
> >>
> >> This functionality is thus a subset of what is already supported, but
> >> since the current solution is geared towards groups a different solution
> >> may be needed (although it is probably possible to reuse parts from the
> >> 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 (that are not
> >> necessarily limited to constrained endpoints, though the focus remains on
> >> deployment ecosystems with a substantial portion of constrained devices).
> >>
> >>
> >>
> >> NEW
> >>
> >> 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 ecosystems with a substantial portion of
> >> constrained devices).
> >>
> >>
> >>
> >> Göran
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 2020-10-15, 19:50, "Ace" <[email-masked]<mailto:[email-masked]>> wrote:
> >>
> >> Hi,
> >>
> >> I would like to start the charter discussion. Here is a draft of a
> >> proposed charter [1].
> >>
> >>
> >>
> >> It seems to be that additional discussion is needed with regard to the
> >> last paragraph related certificate management. In particular the discussion
> >> might revive a discussion that happened in 2017 [2] - when I was not
> >> co-chair of ACE -and considered other expired work such as [3]. Please make
> >> The fundamental question is whether we need certificate management at
> >> this stage. If the answer is yes, and we have multiple proposals, it would
> >> be good to clarify the position of the different proposals and evaluate
> >> whether a selection is needed or not before validating the charter.
> >>
> >>
> >>
> >> Please provide your inputs on the mailing list before October 30. Of
> >> course for minor edits, you may suggest them directly on the google doc.
> >>
> >>
> >>
> >> Yours,
> >>
> >> Daniel
> >>
> >>
> >>
> >> [1]
> >> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing<https://protect2.fireeye.com/v1/url?k=2eaaeb96-7131d344-2eaaab0d-866132fe445e-7e515f25c81762b8&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
> >> <
> >> https://protect2.fireeye.com/v1/url?k=4f3d9c3b-118c475b-4f3ddca0-86e2237f51fb-627e48b069462d70&q=1&e=6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
> >>
> >>
> >> [2]

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

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

--
Daniel Migault
Ericsson

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

---

From: Laurent Toutain <[email-masked]>
Date: Thu, 3 Dec 2020 20:00:44 +0100

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 <daniel.migault=
[email-masked]> 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.
>
> ------------------------------
> *From:* Ace <[email-masked]> on behalf of Dan Garcia <
> [email-masked]>
> *Sent:* Thursday, December 3, 2020 6:10 AM
> *To:* [email-masked] <[email-masked]>
> *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.
>
> 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.
>
> 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."
>
> 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.
> 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://protect2.fireeye.com/v1/url?k=f9dc6551-a6475d83-f9dc25ca-866132fe445e-9c25a5c257a23470&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
>
> 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.
>
> 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 <[email-masked]> wrote:
>
> <https://protect2.fireeye.com/v1/url?k=a01e017d-ff8539af-a01e41e6-866132fe445e-7268e18ca0e30ad7&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
> >
> > On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault <[email-masked]>
> wrote:
> >
> > > Hi Goran,
> > >
> > > [email-masked]> wrote:
> > >
> > >> Hi Daniel,
> > >>
> > >>
> > >>
> > >> On 2020-10-15, 19:50, "Ace" <[email-masked]> wrote:
> > >>
> > >> Hi,
> > >>
> <https://protect2.fireeye.com/v1/url?k=2eaaeb96-7131d344-2eaaab0d-866132fe445e-7e515f25c81762b8&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
> > >> <
> > >>
> Ace mailing [email-masked]://www.ietf.org/mailman/listinfo/ace
>
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

-- 
Laurent Toutain
+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
| Tel: +33 2 22 06 8156    | Tel: + 33 2 99 12 7026                 | Visit
:
| Mob: +33 6 800 75 900    |                                        |
| Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |
http://class.touta.in
| [email-masked]         | [email-masked]    |
+--------------------------+----------------------------------------+

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 4 Dec 2020 10:26:12 +0000

Hi ACE,

I guess EMU is happy to see new deployments and uses of EAP. I think ACE is better suited for taking on this work if there is interest. EMU primarily deals with the base EAP protocol and various EAP authentication methods. We can obviously help with reviewing the document later on.

I would note that EAP-over-foo is generally defined by the lower-layer. So for example, EAP over LAN (EAPOL) is specified by IEEE. In this case, the lower-layer is CoAP so we at the IETF are responsible for specifying it (if there is a desire to do so). A draft for HTTP authentication with EAP was submitted a couple of decades ago: https://tools.ietf.org/html/draft-torvinen-http-eap-01. That was unfortunately never finished. But maybe CoAP will be different and ACE can finish this work item if it chooses to adopt it.

--Mohit

On 12/3/20 3:20 PM, Daniel Migault wrote:
CCing emu, core

Yours,
Daniel
________________________________
From: Ace <[email-masked]><mailto:[email-masked]> on behalf of Dan Garcia <[email-masked]><mailto:[email-masked]>
Sent: Thursday, December 3, 2020 6:10 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [Ace] Proposed charter for ACE (EAP over CoAP?)

Dear all:

Any opinion about this?

Best Regards.

Yours,
Daniel

-Ben

--
Daniel Migault
Ericsson

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

---

From: Daniel Migault <[email-masked]>
Date: Mon, 7 Dec 2020 08:43:28 -0500

Hi,

Please have a look at the latest version of the charter before we move it
forward by the end of the week - December 11.

I added a note on potential WG that could host the CMPv2 over CoAP -
eventually. I am wondering if we should put a note to these WGs.

Yours,
Daniel

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).

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 as needed. [Note that CMPv2 work may also be hosted in
LAMPS (which revisits CMPv2), ANIMA ( which defines CMPv2 as an alternative
to EST) or IOTPS. EAP work has been coordinated with EMU. In any case, if
the work is being considered in ACE, we will make sure the corresponding WG
will follow the progress.]

-- 
Daniel Migault
Ericsson

---

From: Göran Selander <[email-masked]>
Date: Mon, 7 Dec 2020 14:07:40 +0000

+1.

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

Göran

On 2020-12-03, 20:03, "core" <[email-masked]> 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 <daniel.migault=[email-masked]<mailto:daniel.migault=[email-masked]>> wrote:

CCing emu, core

Yours,
Daniel
________________________________________
From: Ace <[email-masked]<mailto:[email-masked]>> on behalf of Dan Garcia <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, December 3, 2020 6:10 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: [Ace] Proposed charter for ACE (EAP over CoAP?)

Dear all:

Any opinion about this?

Best Regards.

Hi,

https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing <https://protect2.fireeye.com/v1/url?k=f9dc6551-a6475d83-f9dc25ca-866132fe445e-9c25a5c257a23470&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>

Yours,
Daniel

-Ben

On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote:
> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing <https://protect2.fireeye.com/v1/url?k=a01e017d-ff8539af-a01e41e6-866132fe445e-7268e18ca0e30ad7&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
>
> >> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing <https://protect2.fireeye.com/v1/url?k=2eaaeb96-7131d344-2eaaab0d-866132fe445e-7e515f25c81762b8&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
> >> <

--
Daniel Migault

Ericsson

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

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

--
Laurent Toutain
+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
| Tel: +33 2 22 06 8156    | Tel: + 33 2 99 12 7026                 | Visit :| Mob: +33 6 800 75 900    |                                        |
| Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |  http://class.touta.in <https://protect2.fireeye.com/v1/url?k=a3f58437-fc325694-a3f5c4ac-86f373f27850-0daaf502d59f9de3&q=1&e=4c9aeb6f-f5eb-4229-b6fb-e4c6abb28354&u=http%3A%2F%2Fclass.touta.in%2F>
| [email-masked]<mailto:[email-masked]>         | [email-masked]<mailto:[email-masked]>    |
+--------------------------+----------------------------------------+

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 07 Dec 2020 15:12:13 +0100

Hi Daniel,

On 2020-12-07, Daniel Migault <[email-masked]> wrote:

> IOTPS.

There is an 'O' missing (IOTOPS), I presume?

Grüße
Olaf

---

From: Daniel Migault <[email-masked]>
Date: Mon, 7 Dec 2020 16:37:23 +0000

Correct and fixed Thanks!
Yours,
Daniel
________________________________
From: Ace <[email-masked]> on behalf of Olaf Bergmann <[email-masked]>
Sent: Monday, December 7, 2020 9:12 AM
To: Daniel Migault <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>; Ace Wg <[email-masked]>
Subject: Re: [Ace] Charter discussion

Hi Daniel,

Grüße
Olaf

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 7 Dec 2020 17:05:38 +0000

As the CMPoverCoAP draft was already discussed in LAMPS and Jim suggested to consider it in ACE, I suggest to drop the Note and come back to a clear statement as discussed at IETF109.

Discussion on the LAMPS Mailing List from June:
https://mailarchive.ietf.org/arch/msg/spasm/uyYCf5sMcxg6xoQFcbe1sPxqVLw/

Hendrik

Von: Ace <[email-masked]> Im Auftrag von Daniel Migault
Gesendet: Montag, 7. Dezember 2020 14:43
An: Benjamin Kaduk <[email-masked]>
Cc: Ace Wg <[email-masked]>
Betreff: Re: [Ace] Charter discussion

Hi,

Please have a look at the latest version of the charter before we move it forward by the end of the week - December 11.

I added a note on potential WG that could host the CMPv2 over CoAP - eventually. I am wondering if we should put a note to these WGs.

Yours,
Daniel

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 as needed. [Note that CMPv2 work may also be hosted in LAMPS (which revisits CMPv2), ANIMA ( which defines CMPv2 as an alternative to EST) or IOTPS. EAP work has been coordinated with EMU. In any case, if the work is being considered in ACE, we will make sure the corresponding WG will follow the progress.]

-Ben

On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote:
> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ccb25631db9264d26e46608d89ab62bde%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637429454498903919%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hWVvEAeTR35%2FlkhB8pzDyW6kc143Q%2B3Dc5Y0f90LnB0%3D&reserved=0>
>
> >> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ccb25631db9264d26e46608d89ab62bde%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637429454498903919%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hWVvEAeTR35%2FlkhB8pzDyW6kc143Q%2B3Dc5Y0f90LnB0%3D&reserved=0>
> >> <
> >> https://protect2.fireeye.com/v1/url?k=4f3d9c3b-118c475b-4f3ddca0-86e2237f51fb-627e48b069462d70&q=1&e=6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D4f3d9c3b-118c475b-4f3ddca0-86e2237f51fb-627e48b069462d70%26q%3D1%26e%3D6924b2a6-e7e5-4ec1-a1af-c94637953dc5%26u%3Dhttps%253A%252F%252Fdocs.google.com%252Fdocument%252Fd%252F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%252Fedit%253Fusp%253Dsharing&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ccb25631db9264d26e46608d89ab62bde%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637429454498913878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=T%2BREJEGJrn6QwtSlTU300gm4eQDkDf6k08zkdR5IYJc%3D&reserved=0>>
> >>
> >>
> >> [2]
> >> https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fminutes-interim-2017-ace-03-201710191300%2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ccb25631db9264d26e46608d89ab62bde%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637429454498913878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=c9FRD3ieuDAHZRY1npHaAqV3SV1aMw%2FCFgoeGS%2BBWig%3D&reserved=0>
> >>
> >> [3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-selander-ace-eals%2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ccb25631db9264d26e46608d89ab62bde%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637429454498923833%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=KcvM1UChtpsBCe7y6%2Fs%2Bv0lEnFcp%2BDfwdjeJqPULeVw%3D&reserved=0>
> >>
> >>
> >>
> >> --
> >>
> >> Daniel Migault
> >>
> >>
> >>
> >> Ericsson
> >>
> >
> >
> > --
> > Daniel Migault
> > Ericsson
> >
>
>
> --
> Daniel Migault
> Ericsson

> https://www.ietf.org/mailman/listinfo/ace<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ccb25631db9264d26e46608d89ab62bde%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637429454498923833%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TxU6PXpO86WQUUiQsl9Waa54%2F%2BWKPOCSEqO6xWmFi9Q%3D&reserved=0>

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ccb25631db9264d26e46608d89ab62bde%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637429454498923833%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TxU6PXpO86WQUUiQsl9Waa54%2F%2BWKPOCSEqO6xWmFi9Q%3D&reserved=0>

--
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Mon, 7 Dec 2020 13:11:03 -0500

Thanks, I was about just sending them a note, but that is maybe not needed.
Just for your information, the note is not part of the charter, but to our
AD/IESG.
Yours, Daniel

On Mon, Dec 7, 2020 at 12:05 PM Brockhaus, Hendrik <
[email-masked]> wrote:

> As the CMPoverCoAP draft was already discussed in LAMPS and Jim suggested
> to consider it in ACE, I suggest to drop the Note and come back to a clear
> statement as discussed at IETF109.
>
>
>
> *Von:* Ace <[email-masked]> *Im Auftrag von * Daniel Migault
> *Gesendet:* Montag, 7. Dezember 2020 14:43
> *An:* Benjamin Kaduk <[email-masked]>
> *Cc:* Ace Wg <[email-masked]>
> *Betreff:* Re: [Ace] Charter discussion
>
>
>
> Hi,
>
>
>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ccb25631db9264d26e46608d89ab62bde%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637429454498903919%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hWVvEAeTR35%2FlkhB8pzDyW6kc143Q%2B3Dc5Y0f90LnB0%3D&reserved=0>
> >
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ccb25631db9264d26e46608d89ab62bde%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637429454498903919%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hWVvEAeTR35%2FlkhB8pzDyW6kc143Q%2B3Dc5Y0f90LnB0%3D&reserved=0>
> > >> <
> > >>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D4f3d9c3b-118c475b-4f3ddca0-86e2237f51fb-627e48b069462d70%26q%3D1%26e%3D6924b2a6-e7e5-4ec1-a1af-c94637953dc5%26u%3Dhttps%253A%252F%252Fdocs.google.com%252Fdocument%252Fd%252F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%252Fedit%253Fusp%253Dsharing&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ccb25631db9264d26e46608d89ab62bde%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637429454498913878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=T%2BREJEGJrn6QwtSlTU300gm4eQDkDf6k08zkdR5IYJc%3D&reserved=0>
> >
> > >>
> > >>
> > >> [2]
> > >>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fminutes-interim-2017-ace-03-201710191300%2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ccb25631db9264d26e46608d89ab62bde%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637429454498913878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=c9FRD3ieuDAHZRY1npHaAqV3SV1aMw%2FCFgoeGS%2BBWig%3D&reserved=0>
> > >>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-selander-ace-eals%2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ccb25631db9264d26e46608d89ab62bde%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637429454498923833%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=KcvM1UChtpsBCe7y6%2Fs%2Bv0lEnFcp%2BDfwdjeJqPULeVw%3D&reserved=0>
> > >>
> > >>
> > >>
> > >> --
> > >>
> > >> Daniel Migault
> > >>
> > >>
> > >>
> > >> Ericsson
> > >>
> > >
> > >
> > > --
> > > Daniel Migault
> > > Ericsson
> > >
> >
> >
> > --
> > Daniel Migault
> > Ericsson
>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ccb25631db9264d26e46608d89ab62bde%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637429454498923833%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TxU6PXpO86WQUUiQsl9Waa54%2F%2BWKPOCSEqO6xWmFi9Q%3D&reserved=0>
>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ccb25631db9264d26e46608d89ab62bde%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637429454498923833%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TxU6PXpO86WQUUiQsl9Waa54%2F%2BWKPOCSEqO6xWmFi9Q%3D&reserved=0>
>
>
>
>
> --
>
> Daniel Migault
>
> Ericsson
>

-- 
Daniel Migault
Ericsson

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Dec 2020 17:09:51 -0500

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   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 8 Dec 2020 07:19:57 +0000

Thank you Daniel for the clarification.
Hendrik

Von: Daniel Migault <[email-masked]>
Gesendet: Montag, 7. Dezember 2020 19:11
An: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>; Ace Wg <[email-masked]>
Betreff: Re: [Ace] Charter discussion

Thanks, I was about just sending them a note, but that is maybe not needed. Just for your information, the note is not part of the charter, but to our AD/IESG.
Yours, Daniel

On Mon, Dec 7, 2020 at 12:05 PM Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>> wrote:
As the CMPoverCoAP draft was already discussed in LAMPS and Jim suggested to consider it in ACE, I suggest to drop the Note and come back to a clear statement as discussed at IETF109.

Discussion on the LAMPS Mailing List from June:
https://mailarchive.ietf.org/arch/msg/spasm/uyYCf5sMcxg6xoQFcbe1sPxqVLw/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspasm%2FuyYCf5sMcxg6xoQFcbe1sPxqVLw%2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cfc495857bcd74afc5da208d89adb7e7f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637429614792205488%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zcSaCtffDHtwVe0C3OZbscFHCktbOip6dKl90YPFMFU%3D&reserved=0>

Hendrik

Von: Ace <[email-masked]<mailto:[email-masked]>> Im Auftrag von Daniel Migault
Gesendet: Montag, 7. Dezember 2020 14:43
An: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
Cc: Ace Wg <[email-masked]<mailto:[email-masked]>>
Betreff: Re: [Ace] Charter discussion

Hi,

Yours,
Daniel

-Ben

On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote:
> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cfc495857bcd74afc5da208d89adb7e7f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637429614792215481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sRetIaCRUI24Ui8Bv78AD9eaEFCB%2BNC5pMGDpEVLnOg%3D&reserved=0>
>
> >> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cfc495857bcd74afc5da208d89adb7e7f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637429614792225474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BkhrBVsN0pXtuqcvXWjBjpDJYTe6f7JcMI%2FcO3z6fOg%3D&reserved=0>
> >> <
> >> https://protect2.fireeye.com/v1/url?k=4f3d9c3b-118c475b-4f3ddca0-86e2237f51fb-627e48b069462d70&q=1&e=6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D4f3d9c3b-118c475b-4f3ddca0-86e2237f51fb-627e48b069462d70%26q%3D1%26e%3D6924b2a6-e7e5-4ec1-a1af-c94637953dc5%26u%3Dhttps%253A%252F%252Fdocs.google.com%252Fdocument%252Fd%252F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%252Fedit%253Fusp%253Dsharing&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cfc495857bcd74afc5da208d89adb7e7f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637429614792225474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IrvfFYuKyUE9%2BhdoqnevuwJjg1V2qKN%2Bc2wKAMTy8is%3D&reserved=0>>
> >>
> >>
> >> [2]
> >> https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fminutes-interim-2017-ace-03-201710191300%2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cfc495857bcd74afc5da208d89adb7e7f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637429614792235469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xFQxHuaeph8%2B%2BDp4PEDB5%2FIO0Bt2wD6rHRgrn%2FUCuYc%3D&reserved=0>
> >>
> >> [3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-selander-ace-eals%2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cfc495857bcd74afc5da208d89adb7e7f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637429614792235469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=S7%2FjJiFcumiZ%2BfJwn046ApVxGnxo7%2BRpI6VjsaEYPHM%3D&reserved=0>
> >>
> >>
> >>
> >> --
> >>
> >> Daniel Migault
> >>
> >>
> >>
> >> Ericsson
> >>
> >
> >
> > --
> > Daniel Migault
> > Ericsson
> >
>
>
> --
> Daniel Migault
> Ericsson

> https://www.ietf.org/mailman/listinfo/ace<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cfc495857bcd74afc5da208d89adb7e7f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637429614792245461%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lNqoEKxf4f3coHPtDY9e4wUZkmpDGabcaSC53PYPJXA%3D&reserved=0>

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cfc495857bcd74afc5da208d89adb7e7f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637429614792255458%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FTJe7zOkWxhRaN%2FfZvMgV7WGodUkn3LP1Z9XfcRF%2F7o%3D&reserved=0>

--
Daniel Migault
Ericsson

--
Daniel Migault
Ericsson

---

From: Dan Garcia <[email-masked]>
Date: Wed, 9 Dec 2020 10:12:22 +0100

Hi Josh,

Thanks for the support.

At first sight, I would say that, from the perspective of a very 
constrained devices and networks, it would be better to directly design 
an EAP lower-layer based on CoAP without introducing any intermediate 
layer.

Best Regards,
Dan.

On 7/12/20 16:50, [email-masked] wrote:
>
> I support this; although I am curious in Dan’s opinion as to whether 
> GSS on top of CoAP is also worth considering, as a way of leveraging 
> the GSS EAP and other mechanisms (such as Kerberos).
>
> Josh
>
> *From:*Emu <[email-masked]> *On Behalf Of *Göran Selander
> *Sent:* 07 December 2020 14:08
> *To:* Laurent Toutain <[email-masked]>; Daniel 
> Migault <daniel.migault=[email-masked]>
> *Cc:* EMU WG <[email-masked]>; [email-masked] WG ([email-masked]) 
> <[email-masked]>; [email-masked]
> *Subject:* Re: [Emu] [core] [Ace] Proposed charter for ACE (EAP over 
> CoAP?)
>
> +1.
>
> On 2020-12-03, 20:03, "core" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Hi,
>
> On Thu, Dec 3, 2020 at 2:20 PM Daniel Migault 
> <daniel.migault=[email-masked] 
> <mailto:daniel.migault=[email-masked]>> wrote:
>
> CCing emu, core
>
> wondering if emu core or any other WG believe there is a better place 
> for it.
>
> From: Ace <[email-masked] <mailto:[email-masked]>> on 
> behalf of Dan Garcia <[email-masked] <mailto:[email-masked]>>
>
> To: [email-masked] <mailto:[email-masked]> <[email-masked] 
> <mailto:[email-masked]>>
>
> (https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00 
> <https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00>), 
> <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>
>
> protocols, such as EST and CMPv2, as well as a transport for 
> authentication protocols such as EAP, and standardize them as needed."
>
> 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.
>
> <https://protect2.fireeye.com/v1/url?k=f9dc6551-a6475d83-f9dc25ca-866132fe445e-9c25a5c257a23470&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing 
> <https://protect2.fireeye.com/v1/url?k=f9dc6551-a6475d83-f9dc25ca-866132fe445e-9c25a5c257a23470&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>>
>
> Yours,
>
> Daniel
>
> support services providing authorized access to crypto keys (that are 
> <https://protect2.fireeye.com/v1/url?k=a01e017d-ff8539af-a01e41e6-866132fe445e-7268e18ca0e30ad7&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing 
> <https://protect2.fireeye.com/v1/url?k=a01e017d-ff8539af-a01e41e6-866132fe445e-7268e18ca0e30ad7&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>>
>
> >
>
> > > [email-masked] <mailto:[email-masked]>> 
> wrote:
>
> > >
>
> > >> Hi Daniel,
>
> > >>
>
> > >>
>
> > >>
>
> <https://protect2.fireeye.com/v1/url?k=2eaaeb96-7131d344-2eaaab0d-866132fe445e-7e515f25c81762b8&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing 
> <https://protect2.fireeye.com/v1/url?k=2eaaeb96-7131d344-2eaaab0d-866132fe445e-7e515f25c81762b8&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>>
>
> > >> <
>
> > >> 
> [email-masked] 
> <mailto:[email-masked]>://www.ietf.org/mailman/listinfo/ace
>
> [email-masked] <mailto:[email-masked]>
>
> <https://www.ietf.org/mailman/listinfo/core>
>
> -- 
>
> Laurent Toutain
>
> | Tel: +33 2 22 06 8156    | Tel: + 33 2 99 12 7026                 | 
> Visit :| Mob: +33 6 800 75 
> 900    |                                        |
>
> http://class.touta.in <http://class.touta.in> 
> <https://protect2.fireeye.com/v1/url?k=a3f58437-fc325694-a3f5c4ac-86f373f27850-0daaf502d59f9de3&q=1&e=4c9aeb6f-f5eb-4229-b6fb-e4c6abb28354&u=http%3A%2F%2Fclass.touta.in%2F 
> <https://protect2.fireeye.com/v1/url?k=a3f58437-fc325694-a3f5c4ac-86f373f27850-0daaf502d59f9de3&q=1&e=4c9aeb6f-f5eb-4229-b6fb-e4c6abb28354&u=http%3A%2F%2Fclass.touta.in%2F>>
>
> | [email-masked] <mailto:[email-masked]> | 
> [email-masked] 
> <mailto:[email-masked]>    |
>
> [email-masked]

---

From: Dan Garcia <[email-masked]>
Date: Wed, 9 Dec 2020 12:45:56 +0100

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.

---

From: Alexander Pelov <[email-masked]>
Date: Wed, 9 Dec 2020 13:12:06 +0100

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 <[email-masked]> 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.

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 9 Dec 2020 14:28:48 +0100

Hello ACE,

> wondering if emu core or any other WG believe there is a better place

If nothing else, I'd be curious to see EAP-over-CoAP this sketched out;
interactions with NOOB. (The "film a blinking LED to get mutual
authentication" sounds particularly promising).

Care would need to be taken to follow CoRE best practices (not that we'd
have a good set of standard recommendations, but at least on concrete
points we usually manage consensus), both because anything built on CoAP
coming from the IETF will be seen as something of a reference example,
and also to leverage its full optimization potential. CCs to core when
this is put on the agenda for ACE interims might be a good idea.

Go for it :-)

Christian

-- 
Es ist nicht deine Schuld, dass die Welt ist, wie sie ist -- es wär' nur
deine Schuld, wenn sie so bleibt.
(You are not to blame for the state of the world, but you would be if
that state persisted.)
  -- Die Ärzte

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 9 Dec 2020 14:52:03 +0100

On 2020-12-09, at 14:28, Christian Amsüss <[email-masked]> 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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Dec 2020 13:55:44 -0500

Dan Garcia <[email-masked]> 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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Dan Garcia <[email-masked]>
Date: Thu, 10 Dec 2020 10:04:28 +0100

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.

---

From: Georgios PAPADOPOULOS <[email-masked]>
Date: Thu, 10 Dec 2020 11:06:48 +0100

Dear all,

+1, I'd be curious to see EAP-over-CoAP.
+1, It seems to me that ACE could be home for such a document.

Best,
Giorgos

> On 3 Dec 2020, at 12:10, Dan Garcia <[email-masked]> wrote:
> 
> 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 <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.
> 
> https://datatracker.ietf.org/doc/html/draft-marin-ace-wg-coap-eap-06 <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/16/3/358>
> https://www.mdpi.com/1424-8220/17/11/2646 <https://www.mdpi.com/1424-8220/17/11/2646>
> 
>> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing <https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing>
>> 
>> Yours, 
>> Daniel
>> 
>> On Tue, Nov 17, 2020 at 6:47 PM Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> wrote:
>> > https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing <https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing>
>> > 
>> > On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault <[email-masked] <mailto:[email-masked]>> wrote:
>> > 
>> > > Hi Goran,
>> > >
>> > > [email-masked] <mailto:[email-masked]>> wrote:
>> > >
>> > >> Hi Daniel,
>> > >>
>> > >>
>> > >>
>> > >> On 2020-10-15, 19:50, "Ace" <[email-masked] <mailto:[email-masked]>> wrote:
>> > >>
>> > >> Hi,
>> > >>
>> > >> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing <https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing>
>> > >> <
>> > >> https://protect2.fireeye.com/v1/url?k=4f3d9c3b-118c475b-4f3ddca0-86e2237f51fb-627e48b069462d70&q=1&e=6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing <https://protect2.fireeye.com/v1/url?k=4f3d9c3b-118c475b-4f3ddca0-86e2237f51fb-627e48b069462d70&q=1&e=6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>>
>> > >>
>> > >>
>> > >> [2]
>> > >> https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/ <https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/>
>> > >>
>> > >> [3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/ <https://datatracker.ietf.org/doc/draft-selander-ace-eals/>
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >>
>> > >> Daniel Migault
>> > >>
>> > >>
>> > >>
>> > >> Ericsson
>> > >>
>> > >
>> > >
>> > > --
>> > > Daniel Migault
>> > > Ericsson
>> > >
>> > 
>> > 
>> > -- 
>> > Daniel Migault
>> > Ericsson
>> 
>> > https://www.ietf.org/mailman/listinfo/ace <https://www.ietf.org/mailman/listinfo/ace>
>> 
>> https://www.ietf.org/mailman/listinfo/ace <https://www.ietf.org/mailman/listinfo/ace>
>> 
>> 
>> -- 
>> Daniel Migault
>> Ericsson
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/ace <https://www.ietf.org/mailman/listinfo/ace>

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 10 Dec 2020 18:43:32 +0100

Hi Dan,

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

Mališa 

From: core <[email-masked]> on behalf of Dan Garcia <[email-masked]>
Date: Thursday 10 December 2020 at 10:06
To: Michael Richardson <[email-masked]>, EMU WG <[email-masked]>, "[email-masked] WG ([email-masked])" <[email-masked]>, "[email-masked]" <[email-masked]>
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.

---

From: Dan Garcia Carrillo <[email-masked]>
Date: Fri, 11 Dec 2020 18:41:27 +0100

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ó:
> *From: *core <[email-masked]> on behalf of Dan Garcia 
> <[email-masked]>
> *Date: *Thursday 10 December 2020 at 10:06
> *To: *Michael Richardson <[email-masked]>, EMU WG 
> <[email-masked]>, "[email-masked] WG ([email-masked])" <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> *Subject: *Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)
>

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 11 Dec 2020 19:45:21 +0100

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 <[email-masked]>
Date: Friday 11 December 2020 at 18:41
To: Mališa Vučinić <[email-masked]>, Michael Richardson <[email-masked]>, EMU WG <[email-masked]>, "[email-masked] WG ([email-masked])" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: <[email-masked]>
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.

Hi Dan,

Mališa 

-->

---

From: Dan Garcia Carrillo <[email-masked]>
Date: Sat, 12 Dec 2020 18:36:53 +0100

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 <[email-masked]>
> *Date: *Friday 11 December 2020 at 18:41
> *To: *Mališa Vučinić <[email-masked]>, Michael Richardson 
> <[email-masked]>, EMU WG <[email-masked]>, "[email-masked] WG 
> ([email-masked])" <[email-masked]>, "[email-masked]" <[email-masked]>
> *Cc: *<[email-masked]>
> My intention was not to turn this conversation into a criticism of 
> your work. “deficiencies” was not the most appropriate word.
>
> 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.
>
> 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.
>
> 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.
>
>     *From: *core <[email-masked]>
>     <mailto:[email-masked]> on behalf of Dan Garcia
>     <[email-masked]> <mailto:[email-masked]>
>     *To: *Michael Richardson <[email-masked]>
>     <mailto:[email-masked]>, EMU WG <[email-masked]>
>     <mailto:[email-masked]>, "[email-masked] WG ([email-masked])"
>     <mailto:[email-masked]([email-masked])> <[email-masked]>
>     <mailto:[email-masked]>, "[email-masked]" <mailto:[email-masked]>
>     <[email-masked]> <mailto:[email-masked]>
>     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.
>
> -->
>