Re: [Ace] Charter discussion

[Daniel Migault <[e-mail]>]

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 <
[e-mail]> 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/
>
>
>
> Hendrik
>
>
>
> *Von:* Ace <[e-mail]> *Im Auftrag von * Daniel Migault
> *Gesendet:* Montag, 7. Dezember 2020 14:43
> *An:* Benjamin Kaduk <[e-mail]>
> *Cc:* Ace Wg <[e-mail]>
> *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 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, 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.]
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Nov 17, 2020 at 6:47 PM Benjamin Kaduk <[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://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>
> >
> > On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault <[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]> 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]> 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://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
>
> > _______________________________________________
> > Ace mailing list
> > [e-mail]
> > 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
> [e-mail]
> 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
>


-- 
Daniel Migault
Ericsson