Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault)

From: Mohit Sahni <[email-masked]>
Date: Tue, 21 Jul 2020 12:58:21 -0700

Hi Daniel,
I had requested, in an earlier email, some time to discuss what changes are
required in the ACE WG charter to adopt my draft for "CMPv2/Lightweight CMP
profile over CoAP transport" (
https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00).
Would it be possible for you to add it to the tentative agenda?

To give some background, this draft is an extension of Light Weight CMP
Profile (
https://tools.ietf.org/html/draft-ietf-lamps-lightweight-cmp-profile-02)
draft currently under development in the LAMPS WG. We discussed the "CMPv2
over CoAP" draft in the LAMPS WG and figured out that ACE WG is a more
appropriate place for this draft. However, Jim suggested that we will need
to modify the charter  of the ACE WG to adopt this draft.

Thanks
Mohit

On Tue, Jul 21, 2020 at 11:22 AM <[email-masked]> wrote:

> Send Ace mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/ace
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ace digest..."
> Today's Topics:
>
>    1. interim meeting planification (Daniel Migault)
>    2. ACE interim meeting tentative (Option2) (Daniel Migault)
>    3. ACE tentative interim meeting (option 1) (Daniel Migault)
>    4. IETF 108 tentative agenda and presentations (Daniel Migault)
>
>
>
> ---------- Forwarded message ----------
> From: Daniel Migault <[email-masked]>
> To: Ace Wg <[email-masked]>
> Cc:
> Bcc:
> Date: Tue, 21 Jul 2020 11:59:22 -0400
> Subject: [Ace] interim meeting planification
> Hi,
>
> Please find a doodle [1] with two time slots for the interim meetings that
> are planned 1 per month the first week of the month 10 AM - 11 AM EST. The
> two proposed days are Monday and Thursday. Please select your preferred day
> by July 26.
>
> I am sending the calendar serie to the ace list so everyone can better see
> how it matches its calendar.
>
> Yours,
>
> Jim and Daniel
>
> [1] https://doodle.com/poll/x2dghwiqmqei6cc8
> --
> Daniel Migault
> Ericsson
>
>
>
> ---------- Forwarded message ----------
> From: Daniel Migault <[email-masked]>
> To: Ace Wg <[email-masked]>
> Cc:
> Bcc:
> Date: Tue, 21 Jul 2020 15:59:52 +0000
> Subject: [Ace] ACE interim meeting tentative (Option2)
>
>
>
> ---------- Forwarded message ----------
> From: Daniel Migault <[email-masked]>
> To: Ace Wg <[email-masked]>
> Cc:
> Bcc:
> Date: Tue, 21 Jul 2020 16:00:38 +0000
> Subject: [Ace] ACE tentative interim meeting (option 1)
>
>
>
>
> ---------- Forwarded message ----------
> From: Daniel Migault <[email-masked]>
> To: Ace Wg <[email-masked]>
> Cc:
> Bcc:
> Date: Tue, 21 Jul 2020 14:22:08 -0400
> Subject: [Ace] IETF 108 tentative agenda and presentations
> Hi,
>
> Please find the tentative agenda [1] of ACE WG at the IETf 108 Wed July
> 29, 2020 11:00 UTC.
>
> Please upload your presentations by July 27 here:
> https://datatracker.ietf.org/meeting/108/session/ace
>
> Yours,
> Jim and Daniel
>
> [1] https://codimd.ietf.org/notes-ietf-108-ace
>
>
> --
> Daniel Migault
> Ericsson
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jul 2020 16:31:05 -0400

> to modify the charter  of the ACE WG to adopt this draft.

We did est-over-coaps [still in the queue], why shouldn't we do cmp-over-coap(s)?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 21 Jul 2020 14:58:25 -0700

> We did est-over-coaps [still in the queue], why shouldn't we do cmp-over-coap(s)?

It may just be that "est-over-coaps is so obviously us" that I didn't check
the charter carefully at that time.  But, at this point, we're probably
overdue for a recharter anyway, as the core framework is making its way to
the IESG.

-Ben

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 22 Jul 2020 07:50:45 +0000

> Von: Ace <[email-masked]> Im Auftrag von Benjamin Kaduk
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.
> org%2Fhtml%2Fdraft-ietf-lamps-lightweight-cmp-profile-
> 02&amp;data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cc3b352cdfd
> 174b0a7e2008d82dc1484f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C
> 0%7C637309655452109222&amp;sdata=QWHu3IEwf4TIIpaW0cvKuMiGXixV1AX
> dws6g0vBQJPY%3D&amp;reserved=0)
> It may just be that "est-over-coaps is so obviously us" that I didn't check the
> charter carefully at that time.  But, at this point, we're probably overdue for a
> recharter anyway, as the core framework is making its way to the IESG.
> 

Steffen and I discussed this with Jim last year in Prague, if I remember correctly, and he recommended to submit cmp-over-coap to ACE and not to LAMPS.
As est-over-coaps was in scope of ACE, I also think it is quite obvious to discuss cmp-over-coap in ACE.
Looking into Mohits draft, cmp-over-coap is much simpler than est-over-coaps, as CMP does not need any binding to an underlying (D)TLS handshake.
If you think this needs rechartering, we should go for it.

- Hendrik

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 22 Jul 2020 13:08:20 +0000

Hi, 

> Looking into Mohits draft, cmp-over-coap is much simpler than
est-over-coaps, as CMP does not need any binding to an underlying (D)TLS
handshake.

Not sure that is accurate. And EST does not bind to the tunnel protocol
either unless proof of possession is used. For now the cmp-over-coap draft
says 

   When the end to end secrecy is desired for CoAP transport, CoAP over
   DTLS [RFC6347] as a transport medium SHOULD be used.

COAP can run over DTLS or plain UDP and in rare cases TCP, TLS and maybe
Websockets. I am not sure someone would run cmp-over-coap over TCP because
then he could just run CMP natively without COAP in the middle. Any
application layer protocol (CMP etc) can run over any transport but I am not
sure there are more transports than the usual ones for cmp-over-coap anyway.

I agree that if this gets picked up it should be by ACE.

I would like to understand what gaps it is filling compared to
est-over-coaps which took a lot of work and where it will be used and
implemented in. 

Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, July 22, 2020 3:51 AM
To: Benjamin Kaduk <[email-masked]>; Michael Richardson
<[email-masked]>
Cc: Mohit Sahni <[email-masked]>; [email-masked];
[email-masked]
Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel
Migault)

> >     > To give some background, this draft is an extension of Light
Weight CMP
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf
.
> >     > draft currently under development in the LAMPS WG. We 
> > discussed the
> "CMPv2
> >     > over CoAP" draft in the LAMPS WG and figured out that ACE WG 
> > is a
> more
> >     > appropriate place for this draft. However, Jim suggested that 
> > we will
> need
> > We did est-over-coaps [still in the queue], why shouldn't we do 
> > cmp-over-
> coap(s)?
> 
> It may just be that "est-over-coaps is so obviously us" that I didn't 
> check the charter carefully at that time.  But, at this point, we're 
> probably overdue for a recharter anyway, as the core framework is making
its way to the IESG.

Steffen and I discussed this with Jim last year in Prague, if I remember
correctly, and he recommended to submit cmp-over-coap to ACE and not to
LAMPS.
As est-over-coaps was in scope of ACE, I also think it is quite obvious to
discuss cmp-over-coap in ACE.
Looking into Mohits draft, cmp-over-coap is much simpler than
est-over-coaps, as CMP does not need any binding to an underlying (D)TLS
handshake.
If you think this needs rechartering, we should go for it.

- Hendrik

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 22 Jul 2020 13:42:25 +0000

Hi Panos,

thnaks for you feedback.

> Von: Panos Kampanakis (pkampana) <[email-masked]>
> 
> Hi,
> 

It is not needed to run CMP over CoAP over TCP. UDP as transport protocol is
fine. Actually CMP over CoAP also does not need DTLS underneath. But it also
does not hinder to have a second line of defense.
As I understand EST, proof-of-possession is purely provided by the
self-signature in PKCS#10. But EST provides the proof-of-identity of the
requesting party by the (D)TLS client authentication bound to the PKCS#10
(tls-unique copied in the P10 password filed). Is this correct?
Such binding is not required for CMP. CMP does not have any requirements in
this regard and provides prove-of-identity by signing the CMP messages. The
advantage is that this prove-of-identity can be end-to-end and not only on
the first hop to the (D)TLS server, like with EST.

> est-over-coaps which took a lot of work and where it will be used and

I am uncertain if I understand your question correctly. Est-over-coaps
described EST transport and not CMP transport on top of CoAP.
One prototypic implementation can be found on
github.com/siemens/embeddedCMP.

- Hendrik

---

From: Daniel Migault <[email-masked]>
Date: Wed, 22 Jul 2020 13:40:20 -0400

Hi Mohit,

We apology for missing your request and thank you for reiterating the
request. We gave you a 15 min [1], if that is not enough, please let us
know.

Yours,
Daniel

On Tue, Jul 21, 2020 at 3:58 PM Mohit Sahni <[email-masked]> wrote:

> Hi Daniel,
> I had requested, in an earlier email, some time to discuss what changes
> are required in the ACE WG charter to adopt my draft for "CMPv2/Lightweight
> CMP profile over CoAP transport" (
>> Please find a doodle [1] with two time slots for the interim meetings
>> that are planned 1 per month the first week of the month 10 AM - 11 AM EST.
>> The two proposed days are Monday and Thursday. Please select your
>> preferred day by July 26.
>>
>> I am sending the calendar serie to the ace list so everyone can better
>> see how it matches its calendar.
>>
>> Yours,
>>
>> Jim and Daniel
>>

-- 
Daniel Migault
Ericsson

---

From: Mohit Sahni <[email-masked]>
Date: Wed, 22 Jul 2020 10:42:13 -0700

Hi Daniel
Thanks for adding this to the agenda. 15 Minutes should be good.

Regards
Mohit

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 24 Jul 2020 14:04:38 +0000

Hi Hendrik, 

Thank you. Understood about the end-to-end protection of CMP and POP. 

I would argue that establishing the end-to-end keys to offer the application
level protection functionality in a scalable way does not come easily. On
the other hand, even CMP allows for an RA trust model instead of end-to-end
POP like EST-coaps does. 

I meant why do we need two enrollment protocols to run over COAP?
est-over-coaps took a long time and a lot of work. The reason we pursued it
is because we were getting requests from vendors that wanted to enroll certs
in constrained environments in the energy sector and industrial automation
and EST was standardized in IEC 62351. Is the cmp-over-coap argument that
you could run it over plan UDP and use out-of-band established, end-to-end
protection the sole motivating reason? 

Rgs, 
Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, July 22, 2020 9:42 AM
To: Panos Kampanakis (pkampana) <[email-masked]>; Benjamin Kaduk
<[email-masked]>; Michael Richardson <[email-masked]>
Cc: Mohit Sahni <[email-masked]>; [email-masked];
[email-masked]
Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel
Migault)

Hi Panos,

thnaks for you feedback.

> est-over-coaps, as CMP does not need any binding to an underlying 
> (D)TLS handshake.
> 
> Not sure that is accurate. And EST does not bind to the tunnel 
> protocol either unless proof of possession is used. For now the 
> cmp-over-coap draft says
> 
> COAP can run over DTLS or plain UDP and in rare cases TCP, TLS and 
> maybe Websockets. I am not sure someone would run cmp-over-coap over 
> TCP because then he could just run CMP natively without COAP in the 
> middle. Any application layer protocol (CMP etc) can run over any 
> transport but I am
not

- Hendrik

---

From: Jim Schaad <[email-masked]>
Date: Fri, 24 Jul 2020 07:32:58 -0700

> From: Ace <[email-masked]> On Behalf Of Panos Kampanakis
> (pkampana)
> Sent: Friday, July 24, 2020 7:05 AM
> To: Brockhaus, Hendrik <[email-masked]>; Benjamin Kaduk
Migault)
> level protection functionality in a scalable way does not come easily. On
the
> other hand, even CMP allows for an RA trust model instead of end-to-end
POP
> like EST-coaps does.

[JLS] EST-coaps does allow for an RA trust model for POP as well.  The RA is
the terminator for the coaps connection.

Jim

> est-over-coaps took a long time and a lot of work. The reason we pursued
it is
> because we were getting requests from vendors that wanted to enroll certs
in
> constrained environments in the energy sector and industrial automation
and
> EST was standardized in IEC 62351. Is the cmp-over-coap argument that you
> could run it over plan UDP and use out-of-band established, end-to-end