Re: [Ace] Charter discussion

[Brockhaus, Hendrik]

Thank you Daniel for the clarification.
Hendrik

Von: Daniel Migault 
Gesendet: Montag, 7. Dezember 2020 19:11
An: Brockhaus, Hendrik (T RDA CST SEA-DE) 
Cc: Benjamin Kaduk ; Ace Wg 
Betreff: Re: [Ace] Charter discussion

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 
mailto:hendrik.brockh...@siemens.com>> 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/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspasm%2FuyYCf5sMcxg6xoQFcbe1sPxqVLw%2F=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cfc495857bcd74afc5da208d89adb7e7f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637429614792205488%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=zcSaCtffDHtwVe0C3OZbscFHCktbOip6dKl90YPFMFU%3D=0>

Hendrik

Von: Ace mailto:ace-boun...@ietf.org>> Im Auftrag von 
Daniel Migault
Gesendet: Montag, 7. Dezember 2020 14:43
An: Benjamin Kaduk mailto:ka...@mit.edu>>
Cc: Ace Wg mailto:ace@ietf.org>>
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 
mailto: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 th

Re: [Ace] Charter discussion

[Daniel Migault]

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 <
hendrik.brockh...@siemens.com> 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  *Im Auftrag von * Daniel Migault
> *Gesendet:* Montag, 7. Dezember 2020 14:43
> *An:* Benjamin Kaduk 
> *Cc:* Ace Wg 
> *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  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 

Re: [Ace] Charter discussion

[Brockhaus, Hendrik]

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  Im Auftrag von Daniel Migault
Gesendet: Montag, 7. Dezember 2020 14:43
An: Benjamin Kaduk 
Cc: Ace Wg 
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 
mailto: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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ccb25631db9264d26e46608d89ab62bde%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637429454498903919%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=hWVvEAeTR35%2FlkhB8pzDyW6k

Re: [Ace] Charter discussion

[Daniel Migault]

Correct and fixed Thanks!
Yours,
Daniel

From: Ace  on behalf of Olaf Bergmann 
Sent: Monday, December 7, 2020 9:12 AM
To: Daniel Migault 
Cc: Benjamin Kaduk ; Ace Wg 
Subject: Re: [Ace] Charter discussion

Hi Daniel,

On 2020-12-07, Daniel Migault  wrote:

> IOTPS.

There is an 'O' missing (IOTOPS), I presume?

Grüße
Olaf

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Charter discussion

[Olaf Bergmann]

Hi Daniel,

On 2020-12-07, Daniel Migault  wrote:

> IOTPS.

There is an 'O' missing (IOTOPS), I presume?

Grüße
Olaf

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Charter discussion

[Daniel Migault]

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  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
> >
> > On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault 
> 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 

Re: [Ace] Charter discussion

[Benjamin Kaduk]

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
> 
> On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault  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"  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]
> >> 

Re: [Ace] Charter discussion

[Daniel Migault]

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

On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault  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"  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=1=6924b2a6-e7e5-4ec1-a1af-c94637953dc5=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

Re: [Ace] Charter discussion

[Daniel Migault]

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 
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"  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=1=6924b2a6-e7e5-4ec1-a1af-c94637953dc5=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
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Charter discussion

[Daniel Migault]

On Tue, Nov 3, 2020 at 5:05 AM Göran Selander 
wrote:

> 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.
>
>
>
My understanding is that it covers anything related to profiles.

>
>
> 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 for the clarification. I added some text to add EST profiles.

> 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"  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=1=6924b2a6-e7e5-4ec1-a1af-c94637953dc5=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
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Charter discussion

[Göran Selander]

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

[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
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Charter discussion

[Daniel Migault]

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

Yours,
Daniel

From: Ace  on behalf of Brockhaus, Hendrik 

Sent: Wednesday, November 4, 2020 12:38 PM
To: Ace Wg ; Panos Kampanakis (pkampana) 
Cc: Göran Selander ; Daniel 
Migault 
Subject: Re: [Ace] Charter discussion


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  Im Auftrag von Panos Kampanakis (pkampana)
Gesendet: Mittwoch, 4. November 2020 04:36
An: Göran Selander ; Daniel 
Migault ; Ace Wg 
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 mailto:ace-boun...@ietf.org>> On Behalf Of 
Göran Selander
Sent: Tuesday, November 03, 2020 5:06 AM
To: Daniel Migault mailto:mglt.i...@gmail.com>>; Ace Wg 
mailto:ace@ietf.org>>
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”



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

Re: [Ace] Charter discussion

[Brockhaus, Hendrik]

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  Im Auftrag von Panos Kampanakis (pkampana)
Gesendet: Mittwoch, 4. November 2020 04:36
An: Göran Selander ; Daniel 
Migault ; Ace Wg 
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 mailto:ace-boun...@ietf.org>> On Behalf Of 
Göran Selander
Sent: Tuesday, November 03, 2020 5:06 AM
To: Daniel Migault mailto:mglt.i...@gmail.com>>; Ace Wg 
mailto:ace@ietf.org>>
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"

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<https://eur01.safel

Re: [Ace] Charter discussion

[Panos Kampanakis (pkampana)]

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  On Behalf Of Göran Selander
Sent: Tuesday, November 03, 2020 5:06 AM
To: Daniel Migault ; Ace Wg 
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”

 

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>
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" mailto: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

Re: [Ace] Charter discussion

[Göran Selander]

On 2020-11-03, 19:45, "Ace"  wrote:

Göran Selander wrote:

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

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 mailto:mcr+i...@sandelman.ca>>   . o 
O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Charter discussion

[Michael Richardson]

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

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

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.

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

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

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Charter discussion

[Göran Selander]

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

[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
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Charter discussion

[Daniel Migault]

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

[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
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace