Subject: [Ace] Call for adoption draft-msahni-ace-cmpv2-coap-transport-01

From: Mohit Sahni <[email-masked]>
Date: Mon, 5 Oct 2020 00:21:05 -0700

Hello Ace WG,
I am presenting the draft-msahni-ace-cmpv2-coap-transport-01 to be adopted
by ACE WG. This document supplements the "*Lightweight CMP Profile" draft (*
https://tools.ietf.org/html/draft-brockhaus-lamps-lightweight-cmp-profile-03
*) *which specify the modifications to the CMPv2 protocol for it to be used
efficiently by the constrained devices for PKI operations.

I discussed this draft in IETF-108 ACE session and the need for the
recharter of ACE WG in order to adopt this draft, to which we had a
consensus. Please state your opinion on whether this draft should be
adopted by ACE WG.

Link to the draft
https://datatracker.ietf.org/doc/draft-msahni-ace-cmpv2-coap-transport/

Regards,
Mohit Sahni

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 5 Oct 2020 08:22:17 +0000

Thanks to Mohit for his request on rechartering and adoption. I support this.

Hendrik

Mohit Sahni <[email-masked]> , Montag, 5. Oktober 2020 09:21

Hello Ace WG,
I am presenting the draft-msahni-ace-cmpv2-coap-transport-01 to be adopted by ACE WG. This document supplements the "Lightweight CMP Profile" draft (https://tools.ietf.org/html/draft-brockhaus-lamps-lightweight-cmp-profile-03<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-brockhaus-lamps-lightweight-cmp-profile-03&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C550460f235af4e93159a08d868ff412f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637374792799175557&sdata=hphTOVfynIH6g4O9FFemyjDwxmEvnvUV6pDAbHHtp5c%3D&reserved=0>) which specify the modifications to the CMPv2 protocol for it to be used efficiently by the constrained devices for PKI operations.

I discussed this draft in IETF-108 ACE session and the need for the recharter of ACE WG in order to adopt this draft, to which we had a consensus. Please state your opinion on whether this draft should be adopted by ACE WG.

Link to the draft https://datatracker.ietf.org/doc/draft-msahni-ace-cmpv2-coap-transport/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-msahni-ace-cmpv2-coap-transport%2F&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C550460f235af4e93159a08d868ff412f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637374792799185509&sdata=rqOJoZNYM3sa9AuL4QrUe5RTXGsIBOGdAxA0Klb2hFA%3D&reserved=0>

Regards,
Mohit Sahni

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 5 Oct 2020 15:44:03 +0000

I oppose adoption.

IETF in the past has come up with SCEP, CMP, CMC and EST, all of them for the most part doing the same thing with minor differences. I don’t think we need two enrollment protocols to run over COAP. We should not repeat mistakes of the past. 

In ACE we have EST-coaps which is done. We worked on it because EST was in IEC 62351 and we needed a solution for some COAP usecases. Since then EST-coaps has been picked up by Fairhair and Thread. 

The argument about L7 protection in CMPv2 could also be satisfied by draft-selander-ace-coap-est-oscore. draft-selander-ace-coap-est-oscore was trying to secure EST over L7 encrypted COSE messages. 

Additionally, I would argue that L7 proof-of-identity is not a strong advantage in an (L)RA trust model for both EST-coaps and CMPv2-coaps. What is more, having the CA trust all potential manufacturer roots in order to do L7 proof of identity will not be trivial unless the CA is a private one. And in a private CA and (L)RA scenario I don’t know that end-to-end proof or identity is that important. 

I oppose adoption unless there is a compelling reason why. Also I am not sure where this draft would be implemented and used. If this is just for one or two vendors I don’t think ACE needs to spend the cycles. 

Thanks,

Panos

From: Ace <[email-masked]> On Behalf Of Mohit Sahni
Sent: Monday, October 05, 2020 3:21 AM
To: Ace Wg <[email-masked]>
Cc: [email-masked]; [email-masked]; Mohit Sahni <[email-masked]>; Brockhaus, Hendrik <[email-masked]>
Subject: [Ace] Call for adoption draft-msahni-ace-cmpv2-coap-transport-01

Hello Ace WG,

I am presenting the draft-msahni-ace-cmpv2-coap-transport-01 to be adopted by ACE WG. This document supplements the "Lightweight CMP Profile" draft (https://tools.ietf.org/html/draft-brockhaus-lamps-lightweight-cmp-profile-03) which specify the modifications to the CMPv2 protocol for it to be used efficiently by the constrained devices for PKI operations. 

Link to the draft https://datatracker.ietf.org/doc/draft-msahni-ace-cmpv2-coap-transport/ 

Regards,

Mohit Sahni

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 8 Oct 2020 06:07:50 +0000

I honor Panos opinion and understand that he whishes to have EST as the one and only enrollment protocol. But also after EST, there were further enrollment protocols standardized, e.g., ACME, OPC-UA GDS, SCEP. But I do not want to argue pro or con a specific protocol. I think we have to accept that there are different protocols with different abilities chosen in different verticals.

The point here is, does the group support Mohits draft on specify CoAP transport for CMP.

Just to recap the discussion from IETF 108:
---------------------snip---------------------
### CoAP Transport for CMP - Mohit Sahni - 5:11

JS: This is here for possible adoption, but the WG is not not expected to have
expertise in the CMP protocol, but just looking at how the CoAP work is done.
DM: Objections to doing this work? No objections registered. DM: Need to
re-charter and then adopt. JS: Recharter does not stop us from doing reviews.
GS: Reading table of contents - multicast and proxy support MS: Don't use
multicast for this.  Only used for service discovery. Need to have proxy
support to get additional security for servers. GS: This is just a transport
draft? MS: Yes.
---------------------snip---------------------

I would appreciate further votes.

Hendrik

Von: Ace <[email-masked]> Im Auftrag von Panos Kampanakis (pkampana)
Gesendet: Montag, 5. Oktober 2020 17:44
An: Mohit Sahni <[email-masked]>; Ace Wg <[email-masked]>
Cc: [email-masked]; [email-masked]; Mohit Sahni <[email-masked]>; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>
Betreff: Re: [Ace] Call for adoption draft-msahni-ace-cmpv2-coap-transport-01

I oppose adoption.

Thanks,
Panos

From: Ace <[email-masked]<mailto:[email-masked]>> On Behalf Of Mohit Sahni
Sent: Monday, October 05, 2020 3:21 AM
To: Ace Wg <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Mohit Sahni <[email-masked]<mailto:[email-masked]>>; Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>>
Subject: [Ace] Call for adoption draft-msahni-ace-cmpv2-coap-transport-01

Hello Ace WG,
I am presenting the draft-msahni-ace-cmpv2-coap-transport-01 to be adopted by ACE WG. This document supplements the "Lightweight CMP Profile" draft (https://tools.ietf.org/html/draft-brockhaus-lamps-lightweight-cmp-profile-03<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-brockhaus-lamps-lightweight-cmp-profile-03&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C569aa1028dda403452b908d86945b7d3%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637375095443650434&sdata=%2FuzMYm2UIhbrSarrugX4w50w8%2B0ArPfSP%2BZvY8UcTT4%3D&reserved=0>) which specify the modifications to the CMPv2 protocol for it to be used efficiently by the constrained devices for PKI operations.

Link to the draft https://datatracker.ietf.org/doc/draft-msahni-ace-cmpv2-coap-transport/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-msahni-ace-cmpv2-coap-transport%2F&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C569aa1028dda403452b908d86945b7d3%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637375095443660389&sdata=TpdqdyKHNxiu1fLAdJxXeot%2BjA9jNV0JVMGJ870H8Ac%3D&reserved=0>

Regards,
Mohit Sahni

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Oct 2020 13:42:40 -0400

Hi, I've read draft-msahni-ace-cmpv2-coap-transport-01.

I think that the major reason to use CMP instead of EST is avoid the need for
DTLS on the constrained client.  As such, use of coaps seems far less
interesting.

In particular, I think that section 4.2, on CoAPs to HTTPS proxy
is just wrong.   I don't see why we need any kind of end to end trust
assertions given that it is CMP.   MITM trust for anchors seems a rather
unwanted thing.

Why can't the EE just be configured to speak to a CoAPS enabled RA (using
it's name), and then transported to the CA via HTTPS.  It is not like
having the TLS MITM proxy is reducing crypto effort for any entity.

I have no fundamental objection to this work, and I think that it should be
adopted.

But, I think that it is worth doing more than just s/http/coap/.

I think that end points should be specified, as well as resource discovery.
I was writing some text (not yet pushed) for BRSKI-ASYNC-ENROLL
about how to do CMP for the "Delay Tolerant Networks" that AE envisions.

On constrained networks, there are some significant tussles between allowing
certificate renewal to be driven by a state machine on the client device vs
by the network itself.

Client devices know when they are awake and can receive renewals, but they
don't know if the network has capacity at that time.

On the other hand, the network knows when it has bandwidth, and it can manage
things.

My approach to CMP would be define a set of resources and then use CORECONF
to access/update them.   I think that:

https://www.ietf.org/id/draft-ietf-netconf-trust-anchors-13.html
https://www.ietf.org/id/draft-ietf-netconf-keystore-20.html

The later offers a CSR leaf that a RA could *retrieve*, and then when a
certificate is available, could push into the keystore.
This also deals with what the trust anchors are.

It could be that some additional leafs are needed to implement some of the
additional CMP specific functionality.

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

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 15 Oct 2020 10:16:03 +0200

Hi Hendrik and all,

> Just to recap the discussion from IETF 108:

As draft-ietf-lamps-lightweight-cmp-profile already is something a
working group in the IETF has decided to spend cycles on, the question
whether or not CMPv2 is something to work on already seems
decided. Given that, after a quick look at
draft-msahni-ace-cmpv2-coap-transport, I do not see a reason why not to
adopt this as well.

I was a bit surprised that you have selected the ACE working group for
this. One thing that might get in our way when doing this in ACE is the
emerging input for draft-ietf-lamps-lightweight-cmp-profile. But
otherwise, I do not see a strong reason for not adopting
draft-msahni-ace-cmpv2-coap-transport.

Grüße
Olaf

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 15 Oct 2020 17:17:01 +0000

Olaf

Thanks for supporting Mohit's draft.

> Von: Olaf Bergmann <[email-masked]>
> Gesendet: Donnerstag, 15. Oktober 2020 10:16
> 
> Hi Hendrik and all,
> 
> 
> I was a bit surprised that you have selected the ACE working group for this. One
> thing that might get in our way when doing this in ACE is the emerging input
> for draft-ietf-lamps-lightweight-cmp-profile. But otherwise, I do not see a
> strong reason for not adopting draft-msahni-ace-cmpv2-coap-transport.

Actually this was first discussed in LAMPS, but as the draft focusses on CoAP transport and not on CMP specifics, the group had the opinion that ACE is the better home as here is the knowledge regarding CoAP.

Hendrik