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 protected]> 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. > > 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> >> >> 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 protected] >> <mailto:[email protected]>> 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 protected] >> > <mailto:[email protected]>> 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 protected] <mailto:[email protected]>> 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 protected] >> > >> <mailto:[email protected]>> 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 protected] <mailto:[email protected]> >> > https://www.ietf.org/mailman/listinfo/ace >> > <https://www.ietf.org/mailman/listinfo/ace> >> >> _______________________________________________ >> Ace mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/ace >> <https://www.ietf.org/mailman/listinfo/ace> >> >> >> -- >> Daniel Migault >> Ericsson >> >> >> _______________________________________________ >> Ace mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/ace >> <https://www.ietf.org/mailman/listinfo/ace> > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
