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

[Brockhaus, Hendrik]

Olaf

Thanks for supporting Mohit's draft.

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

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

[Olaf Bergmann]

Hi Hendrik and all,

"Brockhaus, Hendrik"  writes:

> The point here is, does the group support Mohits draft on specify CoAP
> transport for CMP.
>
>  
>
> 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

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

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

[Mohit Sahni]

Resending it with correct formatting:
===
Hi Michael,
Thanks for going through the draft. Your feedback is very helpful. I
just want to reiterate that the scope of this draft is only how to use
CoAP as a transport protocol for CMP. The work on defining how CMP
protocol itself should work on constrained devices is being done in
the "Light Weight CMP Profile"
https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile/.
Some of your suggestions should be discussed in the context of the
LightWeight CMP profile draft.

Please see my comments inline:

> -- Forwarded message --
> From: Michael Richardson 
> To: Ace Wg 
> Cc: Kent Watsen 
> Bcc:
> Date: Thu, 08 Oct 2020 13:42:40 -0400
> Subject: Re: [Ace] Call for adoption draft-msahni-ace-cmpv2-coap-transport-01
>
> 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.

[M.S.] Section 3 covers the case where EE can talk to RA directly over
CoAPs, the CoAPs to HTTPs proxy in section 4.2 is for the use case
where changes to the existing RA deployment are not desired due to
operational overheads of upgrading the RA to something that supports
CoAP/CoAPs. CoAPs to HTTPs proxy is not something that is required for
the functionality but rather an option to help with easy adoption of
the "Lightweight CMP profile" and CMPv2 protocol for constrained
devices. I will work on making it more clear what are the pros and
cons of using a proxy vs direct communication.

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

[M.S.]  I agree with that.

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

[M.S.]  I will add the endpoint definitions and make resource
discovery more clear in the draft.

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

[M.S.] This is something that I believe is not in the scope of this
draft, This draft only defines how to use the CoAP transport for
carrying the CMP messages. When and what CMP messages are sent should
come under the CMP protocol implementation itself.

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

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

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

[Mohit Sahni]

Hi Michael,
Thanks for going through the draft. Your feedback is very helpful. I just
want to reiterate that the scope of this draft is only how to use CoAP as a
transport protocol for CMP. The work on defining how CMP protocol itself
should work on constrained devices is being done in the "Light Weight CMP
Profile"
https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile/.
Some of your suggestions should be discussed in the context of the
LightWeight CMP profile draft.

Please see my comments inline:


>
> -- Forwarded message --
> From: Michael Richardson 
> To: Ace Wg 
> Cc: Kent Watsen 
> Bcc:
> Date: Thu, 08 Oct 2020 13:42:40 -0400
> Subject: Re: [Ace] Call for adoption
> draft-msahni-ace-cmpv2-coap-transport-01
>
> 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.
>
>  Section 3 covers the case where EE can talk to RA directly over
CoAPs, the CoAPs to HTTPs proxy in section 4.2 is for the use case where
changes to the existing RA deployment are not desired due to operational
overheads of upgrading the RA to something that supports CoAP/CoAPs. CoAPs
to HTTPs proxy is not something that is required for the functionality but
rather an option to help with easy adoption of the "Lightweight CMP
profile" and CMPv2 protocol for constrained devices. I will work on making
it more clear what are the pros and cons of using a proxy vs direct
communication.


> 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 agree with that.

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


 I will add the endpoint definitions and make resource discovery more
clear in the draft.

>
>
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.
>
 This is something that I believe is not in the scope of this draft,
This draft only defines how to use the CoAP transport for carrying the CMP
messages. When and what CMP messages are sent should come under the CMP
protocol implementation itself.


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

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

[Michael Richardson]

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. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Brockhaus, Hendrik]

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  Im Auftrag von Panos Kampanakis (pkampana)
Gesendet: Montag, 5. Oktober 2020 17:44
An: Mohit Sahni ; Ace Wg 
Cc: stripa...@paloaltonetworks.com; saurabh.tripa...@gmail.com; Mohit Sahni 
; Brockhaus, Hendrik (T RDA CST SEA-DE) 

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

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 mailto:ace-boun...@ietf.org>> On Behalf Of 
Mohit Sahni
Sent: Monday, October 05, 2020 3:21 AM
To: Ace Wg mailto:ace@ietf.org>>
Cc: stripa...@paloaltonetworks.com<mailto:stripa...@paloaltonetworks.com>; 
saurabh.tripa...@gmail.com<mailto:saurabh.tripa...@gmail.com>; Mohit Sahni 
mailto:msa...@paloaltonetworks.com>>; Brockhaus, 
Hendrik mailto:hendrik.brockh...@siemens.com>>
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=02%7C01%7Chendrik.brockhaus%40siemens.com%7C569aa1028dda403452b908d86945b7d3%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637375095443650434=%2FuzMYm2UIhbrSarrugX4w50w8%2B0ArPfSP%2BZvY8UcTT4%3D=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=02%7C01%7Chendrik.brockhaus%40siemens.com%7C569aa1028dda403452b908d86945b7d3%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637375095443660389=TpdqdyKHNxiu1fLAdJxXeot%2BjA9jNV0JVMGJ870H8Ac%3D=0>

Regards,
Mohit Sahni

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

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

[Panos Kampanakis (pkampana)]

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  On Behalf Of Mohit Sahni
Sent: Monday, October 05, 2020 3:21 AM
To: Ace Wg 
Cc: stripa...@paloaltonetworks.com; saurabh.tripa...@gmail.com; Mohit Sahni 
; Brockhaus, Hendrik 

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. 

 

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

 



smime.p7s
Description: S/MIME cryptographic signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Brockhaus, Hendrik]

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

Hendrik

Mohit Sahni  , 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)
 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

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

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

[Mohit Sahni]

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