Subject: Re: [Ace] Charter discussion

From: Göran Selander <[email-masked]>
Date: Tue, 3 Nov 2020 10:05:44 +0000

Hi Daniel, and all,

Some comments on the proposed charter and your mail, sorry for late response.

1.
”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”

I take it this text covers (should the WG want to adopt):

  *   draft-tiloca-ace-group-oscore-profile
  *   an ACE-EDHOC profile (i.e. the POST /token response and the access token provision information to support authentication with EDHOC, e.g. raw public key of the other party). Such a profile could provide good trust management properties, potentially at the cost of a larger access token etc.

Right?

2.
”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.”

As I remember it, the outcome of this discussion was – in line with the mindset of EST – that it is beneficial to re-use authentication and communication security appropriate for actual use case. If coaps is suitable for a particular use case, then it makes sense to protect also the enrolment procedure with this protocol. But whereas the security protocol is coaps instead of https, the enrolment functionality and semantics should reuse that of EST, possibly profiled for the new setting: [4].

In the same spirit there was support at the meeting [2] to specify protection of EST payloads profiled for use with OSCORE as communication security protocol, together with a suitable AKE for authentication. Following the adoption of EDHOC in LAKE this work has now been revived [5]. IMHO the reasoning above still makes sense.

With this in mind, and taking into account recent discussion on the list, perhaps this part of the charter:

”The Working Group will standardize how to use Constrained Application Protocol (CoAP) as a Transport Medium for the Certificate management protocol version 2 (CMPv2).   ”

should be rephrased or complemented with the reasoning above, for example:

The scope of the Working Group includes profiles of the Enrolment over Secure Transport (EST) transported with the Constrained Application Protocol (CoAP)”

Thanks
Göran

[4] https://tools.ietf.org/html/draft-ietf-ace-coap-est
[5] https://tools.ietf.org/html/draft-selander-ace-coap-est-oscore

On 2020-10-15, 19:50, "Ace" <[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://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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Nov 2020 12:28:03 -0500

<#secure method=pgpmime mode=sign>

Göran Selander wrote:
    > In the same spirit there was support at the meeting [2] to specify
    > protection of EST payloads profiled for use with OSCORE as
    > communication security protocol, together with a suitable AKE for
    > authentication. Following the adoption of EDHOC in LAKE this work has
    > now been revived [5]. IMHO the reasoning above still makes sense.

    > ”The Working Group will standardize how to use Constrained Application
    > Protocol (CoAP) as a Transport Medium for the Certificate management
    > protocol version 2 (CMPv2).   ”

Note that CMPv2 is being revised in LAMPS, and that the ANIMA
brski-async-enroll is specifying CMPv2 as an alternative for EST in an
onboarding flow.

I further expect to propose text to brski-async-enroll to do CMPv2 via
CoAP multicast + CORECONF.
I'd rather do this work in the proposed IOTOPS WG, but I don't really
understand how that is working out yet.

As such, there is no need to find another place for to do CMPv2/over CoAP.

    > The scope of the Working Group includes profiles of the Enrolment over Secure Transport (EST) transported with the Constrained Application Protocol (CoAP)”

Is this a re-interpretation of the charter, or a proposed charter change?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Göran Selander <[email-masked]>
Date: Tue, 3 Nov 2020 18:58:40 +0000

On 2020-11-03, 19:45, "Ace" <[email-masked]> wrote:

This is a draft proposed change. Other parts of the new charter text describes both work that has been done and work that may come. This text is intended to capture both.

Göran

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

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

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 4 Nov 2020 03:35:45 +0000

I support the addition of draft-selander-ace-coap-est-oscore in the Charter
as it introduces OSCORE with its advantages in constrained environments for
EST which is already standardized in EST-coaps in ACE. 

As I have said before, I oppose the addition of CMPv2 over COAP in the
charter. Summarizing the reasons here again for brevity:

- we should not repeat the mistakes of the past and introduce multiple
protocols doing the same thing (cert enrollment or management) over COAP
unless there is a compelling reason. To answer your other question Daniel, I
don’t think we need a new certificate management protocol at this stage. 

- I am not convinced of the technical advantages of using CMPv2 over COAP in
constrained environments. 

- I have not seen overwhelming support for the draft in the list other than
Michael saying “why not” and Steffen and Hendrik (from Siemens) clearly
supporting it. Also, minutes from IETF-108 say “DM: Objections to doing this
work? No objections registered”. I was not there to oppose, but I would not
call that overwhelming active support either. 

- it is not clear who intends to use and implement the draft. If it is a one
or two vendor thing then I don’t think ACE should spend the cycles. I have
not seen many people chiming in that want to the draft and are willing to
review. 

Rgs,

Panos

From: Ace <[email-masked]> On Behalf Of Göran Selander
Sent: Tuesday, November 03, 2020 5:06 AM
To: Daniel Migault <[email-masked]>; Ace Wg <[email-masked]>
Subject: Re: [Ace] Charter discussion

Hi Daniel, and all,

Some comments on the proposed charter and your mail, sorry for late
response.  

1.

”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”

*	draft-tiloca-ace-group-oscore-profile
*	an ACE-EDHOC profile (i.e. the POST /token response and the access
token provision information to support authentication with EDHOC, e.g. raw
public key of the other party). Such a profile could provide good trust
management properties, potentially at the cost of a larger access token etc.

Right?

2.

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

As I remember it, the outcome of this discussion was – in line with the
mindset of EST – that it is beneficial to re-use authentication and
communication security appropriate for actual use case. If coaps is suitable
for a particular use case, then it makes sense to protect also the enrolment
procedure with this protocol. But whereas the security protocol is coaps
instead of https, the enrolment functionality and semantics should reuse
that of EST, possibly profiled for the new setting: [4]. 

In the same spirit there was support at the meeting [2] to specify
protection of EST payloads profiled for use with OSCORE as communication
security protocol, together with a suitable AKE for authentication.
Following the adoption of EDHOC in LAKE this work has now been revived [5].
IMHO the reasoning above still makes sense.

With this in mind, and taking into account recent discussion on the list,
perhaps this part of the charter:

The scope of the Working Group includes profiles of the Enrolment over
Secure Transport (EST) transported with the Constrained Application Protocol
(CoAP)” 

Thanks

Göran

[4]  <https://tools.ietf.org/html/draft-ietf-ace-coap-est>
https://tools.ietf.org/html/draft-ietf-ace-coap-est

 

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/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDi
ptY/edit?usp=sharing
<https://protect2.fireeye.com/v1/url?k=4f3d9c3b-118c475b-4f3ddca0-86e2237f51
fb-627e48b069462d70
<https://protect2.fireeye.com/v1/url?k=4f3d9c3b-118c475b-4f3ddca0-86e2237f51
fb-627e48b069462d70&q=1&e=6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u=https%3A%2F
%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoD
iptY%2Fedit%3Fusp%3Dsharing>
&q=1&e=6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u=https%3A%2F%2Fdocs.google.com%
2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3
Dsharing> 

[2]
https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/

-- 

Daniel Migault

Ericsson

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 4 Nov 2020 17:38:28 +0000

Panos, thank you for explaining you position. I understand that you support EST. I already expressed my position and arguments in favor of CMP. :-)
As you see the authentication provided by binding the CSR to the TLS handshake as a pro of EST, I see in many environments exactly this as a drawback of EST and a pro of CMP having all needed security on the application layer. I do not see, why this should not be valid when using CoAP instead of HTTP.
As already pointed out, I do not believe we can address all requirements out there by one certificate enrollment/management protocol.

Important from my perspective is, as Panos also says, there are currently four votes in favor and only one clear vote against the adoption. Or did I miss further votes?

Hendrik

Von: Ace <[email-masked]> Im Auftrag von Panos Kampanakis (pkampana)
Gesendet: Mittwoch, 4. November 2020 04:36
An: Göran Selander <goran.selander=[email-masked]>; Daniel Migault <[email-masked]>; Ace Wg <[email-masked]>
Betreff: Re: [Ace] Charter discussion

I support the addition of draft-selander-ace-coap-est-oscore in the Charter as it introduces OSCORE with its advantages in constrained environments for EST which is already standardized in EST-coaps in ACE.

As I have said before, I oppose the addition of CMPv2 over COAP in the charter. Summarizing the reasons here again for brevity:
- we should not repeat the mistakes of the past and introduce multiple protocols doing the same thing (cert enrollment or management) over COAP unless there is a compelling reason. To answer your other question Daniel, I don't think we need a new certificate management protocol at this stage.
- I am not convinced of the technical advantages of using CMPv2 over COAP in constrained environments.
- I have not seen overwhelming support for the draft in the list other than Michael saying "why not" and Steffen and Hendrik (from Siemens) clearly supporting it. Also, minutes from IETF-108 say "DM: Objections to doing this work? No objections registered". I was not there to oppose, but I would not call that overwhelming active support either.
- it is not clear who intends to use and implement the draft. If it is a one or two vendor thing then I don't think ACE should spend the cycles. I have not seen many people chiming in that want to the draft and are willing to review.

Rgs,
Panos

From: Ace <[email-masked]<mailto:[email-masked]>> On Behalf Of Göran Selander
Sent: Tuesday, November 03, 2020 5:06 AM
To: Daniel Migault <[email-masked]<mailto:[email-masked]>>; Ace Wg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ace] Charter discussion

Hi Daniel, and all,

1.
"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"

Right?

2.
"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."

As I remember it, the outcome of this discussion was - in line with the mindset of EST - that it is beneficial to re-use authentication and communication security appropriate for actual use case. If coaps is suitable for a particular use case, then it makes sense to protect also the enrolment procedure with this protocol. But whereas the security protocol is coaps instead of https, the enrolment functionality and semantics should reuse that of EST, possibly profiled for the new setting: [4].

"The Working Group will standardize how to use Constrained Application Protocol (CoAP) as a Transport Medium for the Certificate management protocol version 2 (CMPv2).   "

The scope of the Working Group includes profiles of the Enrolment over Secure Transport (EST) transported with the Constrained Application Protocol (CoAP)"

Thanks
Göran

[4] https://tools.ietf.org/html/draft-ietf-ace-coap-est<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-coap-est&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C27193ea305fb4be4501e08d88072ca26%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637400577806351097%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Nd0%2B2%2B9QCiQX905x8eeFATC2s5nxgvPElL%2FEd3x9zHc%3D&reserved=0>
[5] https://tools.ietf.org/html/draft-selander-ace-coap-est-oscore<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-selander-ace-coap-est-oscore&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C27193ea305fb4be4501e08d88072ca26%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637400577806361092%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=FhwPXjvDW%2Fio6WdTN8ca5sMYx754V7332qxGNjrCdQE%3D&reserved=0>

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

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%7C27193ea305fb4be4501e08d88072ca26%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637400577806371088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Wx02SgrYvA%2BBaoqY8Cl6e1jQXY9IzDNSOekqSl7y9cc%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%7C27193ea305fb4be4501e08d88072ca26%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637400577806371088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hN20xt76IQDFPFNENNE3kwJgFMWrFgh0N5m5Aib4Mx4%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%7C27193ea305fb4be4501e08d88072ca26%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637400577806381083%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oPHqgbrFmyVbHWeXzn4xmQLWh%2FPmXMS%2BpjrTPTWrmGo%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%7C27193ea305fb4be4501e08d88072ca26%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637400577806391076%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=X4Fe%2B%2Bd0lSti0geRyNzXdINWAx3ym%2FS%2FO2zThQ0icKc%3D&reserved=0>

--
Daniel Migault

Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Wed, 4 Nov 2020 18:00:47 +0000

Just one clarification adoption is not based on vote, but a common understanding this is useful.

Yours,
Daniel
________________________________
From: Ace <[email-masked]> on behalf of Brockhaus, Hendrik <[email-masked]>
Sent: Wednesday, November 4, 2020 12:38 PM
To: Ace Wg <[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]>
Cc: Göran Selander <goran.selander=[email-masked]>; Daniel Migault <[email-masked]>
Subject: Re: [Ace] Charter discussion

Hendrik

- we should not repeat the mistakes of the past and introduce multiple protocols doing the same thing (cert enrollment or management) over COAP unless there is a compelling reason. To answer your other question Daniel, I don’t think we need a new certificate management protocol at this stage.

- I have not seen overwhelming support for the draft in the list other than Michael saying “why not” and Steffen and Hendrik (from Siemens) clearly supporting it. Also, minutes from IETF-108 say “DM: Objections to doing this work? No objections registered”. I was not there to oppose, but I would not call that overwhelming active support either.

- it is not clear who intends to use and implement the draft. If it is a one or two vendor thing then I don’t think ACE should spend the cycles. I have not seen many people chiming in that want to the draft and are willing to review.

Rgs,

Panos

Hi Daniel, and all,

1.

Right?

2.

Thanks

Göran

[4] https://tools.ietf.org/html/draft-ietf-ace-coap-est<https://protect2.fireeye.com/v1/url?k=e3b2c887-bc29f1c4-e3b2881c-861fcb972bfc-e9c51ac16743ab01&q=1&e=ec9e57b6-0c6f-4f39-a84d-6538bd0dc9e8&u=https%3A%2F%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Ftools.ietf.org%252Fhtml%252Fdraft-ietf-ace-coap-est%26data%3D04%257C01%257Chendrik.brockhaus%2540siemens.com%257C27193ea305fb4be4501e08d88072ca26%257C38ae3bcd95794fd4addab42e1495d55a%257C1%257C1%257C637400577806351097%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DNd0%252B2%252B9QCiQX905x8eeFATC2s5nxgvPElL%252FEd3x9zHc%253D%26reserved%3D0>

[5] https://tools.ietf.org/html/draft-selander-ace-coap-est-oscore<https://protect2.fireeye.com/v1/url?k=659ca4de-3a079d9d-659ce445-861fcb972bfc-29faa500f5edd2da&q=1&e=ec9e57b6-0c6f-4f39-a84d-6538bd0dc9e8&u=https%3A%2F%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Ftools.ietf.org%252Fhtml%252Fdraft-selander-ace-coap-est-oscore%26data%3D04%257C01%257Chendrik.brockhaus%2540siemens.com%257C27193ea305fb4be4501e08d88072ca26%257C38ae3bcd95794fd4addab42e1495d55a%257C1%257C1%257C637400577806361092%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DFhwPXjvDW%252Fio6WdTN8ca5sMYx754V7332qxGNjrCdQE%253D%26reserved%3D0>

Hi,

Yours,

Daniel

[1] https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing<https://protect2.fireeye.com/v1/url?k=7754b41f-28cf8d5c-7754f484-861fcb972bfc-a4c99ab0684a00fa&q=1&e=ec9e57b6-0c6f-4f39-a84d-6538bd0dc9e8&u=https%3A%2F%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdocs.google.com%252Fdocument%252Fd%252F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%252Fedit%253Fusp%253Dsharing%26data%3D04%257C01%257Chendrik.brockhaus%2540siemens.com%257C27193ea305fb4be4501e08d88072ca26%257C38ae3bcd95794fd4addab42e1495d55a%257C1%257C1%257C637400577806371088%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DWx02SgrYvA%252BBaoqY8Cl6e1jQXY9IzDNSOekqSl7y9cc%253D%26reserved%3D0> <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=0aa5fcc1-553ec582-0aa5bc5a-861fcb972bfc-999d471eb771d7cd&q=1&e=ec9e57b6-0c6f-4f39-a84d-6538bd0dc9e8&u=https%3A%2F%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fprotect2.fireeye.com%252Fv1%252Furl%253Fk%253D4f3d9c3b-118c475b-4f3ddca0-86e2237f51fb-627e48b069462d70%2526q%253D1%2526e%253D6924b2a6-e7e5-4ec1-a1af-c94637953dc5%2526u%253Dhttps%25253A%25252F%25252Fdocs.google.com%25252Fdocument%25252Fd%25252F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%25252Fedit%25253Fusp%25253Dsharing%26data%3D04%257C01%257Chendrik.brockhaus%2540siemens.com%257C27193ea305fb4be4501e08d88072ca26%257C38ae3bcd95794fd4addab42e1495d55a%257C1%257C0%257C637400577806371088%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DhN20xt76IQDFPFNENNE3kwJgFMWrFgh0N5m5Aib4Mx4%253D%26reserved%3D0>>

[2] https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/<https://protect2.fireeye.com/v1/url?k=edf7e7da-b26cde99-edf7a741-861fcb972bfc-cf1ac46197fd50c3&q=1&e=ec9e57b6-0c6f-4f39-a84d-6538bd0dc9e8&u=https%3A%2F%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fminutes-interim-2017-ace-03-201710191300%252F%26data%3D04%257C01%257Chendrik.brockhaus%2540siemens.com%257C27193ea305fb4be4501e08d88072ca26%257C38ae3bcd95794fd4addab42e1495d55a%257C1%257C1%257C637400577806381083%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DoPHqgbrFmyVbHWeXzn4xmQLWh%252FPmXMS%252BpjrTPTWrmGo%253D%26reserved%3D0>

[3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/<https://protect2.fireeye.com/v1/url?k=e5138516-ba88bc55-e513c58d-861fcb972bfc-a51690574057d87e&q=1&e=ec9e57b6-0c6f-4f39-a84d-6538bd0dc9e8&u=https%3A%2F%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-selander-ace-eals%252F%26data%3D04%257C01%257Chendrik.brockhaus%2540siemens.com%257C27193ea305fb4be4501e08d88072ca26%257C38ae3bcd95794fd4addab42e1495d55a%257C1%257C1%257C637400577806391076%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DX4Fe%252B%252Bd0lSti0geRyNzXdINWAx3ym%252FS%252FO2zThQ0icKc%253D%26reserved%3D0>

--

Daniel Migault

Ericsson

---

From: Göran Selander <[email-masked]>
Date: Fri, 13 Nov 2020 15:26:00 +0000

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

Yours,
Daniel

--
Daniel Migault

Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Tue, 17 Nov 2020 18:01:19 -0500

On Tue, Nov 3, 2020 at 5:05 AM Göran Selander <[email-masked]>
wrote:

> ”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”
>
>
>
>    - draft-tiloca-ace-group-oscore-profile
>    - an ACE-EDHOC profile (i.e. the POST /token response and the access
My understanding is that it covers anything related to profiles.

> 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.
> ”
>
>
>
> communication security appropriate for actual use case. If coaps is
> suitable for a particular use case, then it makes sense to protect also the
> enrolment procedure with this protocol. But whereas the security protocol
> is coaps instead of https, the enrolment functionality and semantics should
> reuse that of EST, possibly profiled for the new setting: [4].
>
>
>
> Secure Transport (EST) transported with the Constrained Application
> Protocol (CoAP)”
>

Thanks for the clarification. I added some text to add EST profiles.

> 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.
>
>
>
> 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=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]

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Tue, 17 Nov 2020 18:02:07 -0500

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]>
wrote:

> 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).
>
>
>
> The Working Group is charged with maintenance of the framework and
> 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
> 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
>
>
>
>
>
>
>

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Tue, 17 Nov 2020 18:16:48 -0500

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]

On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault <[email-masked]> wrote:

> On Fri, Nov 13, 2020 at 10:26 AM Göran Selander <
> [email-masked]> wrote:
>
>> Hi Daniel,
>>
>>
>>
>> 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.
>>
>>
>>
>> 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

-- 
Daniel Migault
Ericsson

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Nov 2020 15:47:00 -0800

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

> [email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Wed, 18 Nov 2020 02:08:46 -0500

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:

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]> wrote:

> 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]
> > >>

-- 
Daniel Migault
Ericsson