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

[Dan Garcia <[e-mail]>]

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, [e-mail] 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 <[e-mail]> *On Behalf Of *Göran Selander
> *Sent:* 07 December 2020 14:08
> *To:* Laurent Toutain <[e-mail]>; Daniel 
> Migault <daniel.migault=[e-mail]>
> *Cc:* EMU WG <[e-mail]>; [e-mail] WG ([e-mail]) 
> <[e-mail]>; [e-mail]
> *Subject:* Re: [Emu] [core] [Ace] Proposed charter for ACE (EAP over 
> CoAP?)
>
> +1.
>
> (The recently updated ACE charter should cover this work.)
>
> Göran
>
> On 2020-12-03, 20:03, "core" <[e-mail] 
> <mailto:[e-mail]>> 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=[e-mail] 
> <mailto:daniel.migault=[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> on 
> behalf of Dan Garcia <[e-mail] <mailto:[e-mail]>>
>
> Sent: Thursday, December 3, 2020 6:10 AM
>
> To: [e-mail] <mailto:[e-mail]> <[e-mail] 
> <mailto:[e-mail]>>
>
> 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 
> <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://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>
>
> 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> 
> <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
>
> 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 <[e-mail] 
> <mailto:[e-mail]>> 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> 
> <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>>
>
> >
>
> > On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault <[e-mail] 
> <mailto:[e-mail]>> 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 <
>
> > > [e-mail] <mailto:[e-mail]>> 
> 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" <[e-mail] 
> <mailto:[e-mail]>> 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=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>>
>
> > >> <
>
> > >> 
> 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
>
> > [e-mail] <mailto:[e-mail]>
>
> > https://www.ietf.org/mailman/listinfo/ace 
> <https://www.ietf.org/mailman/listinfo/ace>
>
> _______________________________________________
>
> Ace mailing list
>
> [e-mail] <mailto:[e-mail]>
>
> https://www.ietf.org/mailman/listinfo/ace 
> <https://www.ietf.org/mailman/listinfo/ace>
>
> -- 
>
> Daniel Migault
>
> Ericsson
>
> _______________________________________________
>
> Ace mailing list
>
> [e-mail] 
> <mailto:[e-mail]>://www.ietf.org/mailman/listinfo/ace
>
> _______________________________________________
>
> core mailing list
>
> [e-mail] <mailto:[e-mail]>
>
> https://www.ietf.org/mailman/listinfo/core 
> <https://www.ietf.org/mailman/listinfo/core>
>
> -- 
>
> Laurent Toutain
>
> +--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
>
> | Tel: [phone]    | Tel: + 33 2 99 12 7026                 | 
> Visit :| Mob: [phone] 
> 900    |                                        |
>
> | Fax: [phone]    | Fax: [phone]                  | 
> 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>>
>
> | [e-mail] <mailto:[e-mail]> | 
> [e-mail] 
> <mailto:[e-mail]>    |
>
> +--------------------------+----------------------------------------+
>
>
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu