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= 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 <ace-boun...@ietf.org> on behalf of Dan Garcia < > dan.gar...@um.es> > *Sent:* Thursday, December 3, 2020 6:10 AM > *To:* a...@ietf.org <a...@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 > <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 <ka...@mit.edu> 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://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 <mglt.i...@gmail.com> > 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 < > > > goran.selan...@ericsson.com> 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" <ace-boun...@ietf.org> 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://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] > > >> > https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/ > > >> > > >> [3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/ > > >> > > >> > > >> > > >> -- > > >> > > >> Daniel Migault > > >> > > >> > > >> > > >> Ericsson > > >> > > > > > > > > > -- > > > Daniel Migault > > > Ericsson > > > > > > > > > -- > > Daniel Migault > > Ericsson > > > _______________________________________________ > > Ace mailing list > > a...@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > a...@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > > > -- > Daniel Migault > Ericsson > > _______________________________________________ > Ace mailing listAce@ietf.orghttps://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > core mailing list > c...@ietf.org > 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 | laur...@touta.in | laurent.tout...@telecom-bretagne.eu | +--------------------------+----------------------------------------+
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
