Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

["Brockhaus, Hendrik" <[e-mail]>]

OK, understood. Thank you for the clarification.
Let us see what is finally needed for Max use cases.
See an explanation on the needed CMP update inline.

Von: Panos Kampanakis (pkampana) <[e-mail]>
Gesendet: Freitag, 10. Mai 2019 19:29
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <[e-mail]>; Dr. Pala <[e-mail]>; [e-mail]
Betreff: RE: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

> tailor the features of CMP to the needed subset and specify this subset precisely to ease interoperable implementations

You are creating a profile for CMP with a subset of its feature and minor updates to the protocol itself. I was not sure if the subset you need for industrial automation will match exactly the simplified profile Max needs for the EAP-CREDS.

[Bro] As discussed with Jim, the goal is to keep the very limited changes to CMP in a separate I-D and do the tailoring in the profile document.
Finally there is only one real change to better support ECC and post-quantum algorithms in CMP.
--> Change EncryptedValue to EncryptedKey to also support EnvelopedData.
As EncryptedKey is a choice of EncryptedValue and EnvelopedData this change should be backward compatible. Therefore I do not see much problems there.
Everything else are more clarification topics that are of general value for CMP from my point of view. This is why I would suggest to put them into the CMP updates document, but they could also be shifted to the CMP profile. This can be discussed and decides in the WG then.


From: Spasm <[e-mail]<mailto:[e-mail]>> On Behalf Of Brockhaus, Hendrik
Sent: Friday, May 10, 2019 3:11 AM
To: Panos Kampanakis (pkampana) <[e-mail]<mailto:[e-mail]>>; Dr. Pala <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Panos

I am not sure if I got your point right. Can you explain the difference you make between 'Hendrik's profile' and 'CMP native'.

Regardless of the very limited changes to be covered in a CMP updates I-D, the goal of our profile is not to change CMP but to ease its use. Therefore I would say that our profile also uses CMP native.
If Max has further certificate management uses cases, not yet covered in the profile, I am happy to specify those together with him making use of the existing CMP mechanisms.
The purpose of the CMP profile is to tailor the features of CMP to the needed subset and specify this subset precisely to ease interoperable implementations.

Hendrik

Von: Spasm <[e-mail]<mailto:[e-mail]>> Im Auftrag von Panos Kampanakis (pkampana)
Gesendet: Donnerstag, 9. Mai 2019 20:56
An: Dr. Pala <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Betreff: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Max,

> First of all, this work is something I needed to do for the EAP-CREDS (Credentials Management over EAP) work (we need a simplified profile for the EAP-CREDS to work :D).

Is this the same profile proposed in Hendrik's draft or a different one?

I don't question that CMP has it uses, but are the rest of the usecases you listed out interested in using Hendrik's profile or are they just interested in CMP native?

Rgs,
Panos

From: Spasm <[e-mail]<mailto:[e-mail]>> On Behalf Of Dr. Pala
Sent: Wednesday, May 08, 2019 7:12 PM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)


Hi Hendrik, all,

I too support this effort and I have few use-cases that might be relevant.

First of all, this work is something I needed to do for the EAP-CREDS (Credentials Management over EAP) work (we need a simplified profile for the EAP-CREDS to work :D).

Another important use case we have is related to medical devices (we have been working with CMI for a while now): in that environment we need to use reasonably-lived certificates (not the usual 20yrs device cert) with frequent renewals: when trying to select a simple protocol, CMP seemed the right choice over others because of its ease of implementation and flexibility.

Another use-case is within Wireless Broadband Alliance (WBA) - there, we are working to define and deploy a RadSec-only deployment for a WBA-centric roaming infrastructure, and part of that work is to define how to deliver server-side (but, in the future, also client-side via EAP-CREDS :D) certificates.

We are also evaluating the deployment of the same (or very similar) approach for the DOCSIS(r) standard (Cable Networks).

I also want to point out that CMP is already used in 3gpp (the very basic version) in their SIM-based (only for an initial authentication) certificate provisioning system (well, just the very basic of the protocol here).

Last but not least, I do like CMP because it allows me to use it independently from the transport protocol, which is a huge win for me (e.g., when granting access to the network and connectivity is not there yet, I want to be able to provision/manage the credentials even before the device goes online). Something like ACME, for example, it is completely useless for all my use-cases (and super inefficient :D).

I will be happy to provide my input for the work, if needed :D

Just my 2 cents...

Cheers,
Max


On 5/8/19 9:02 AM, Brockhaus, Hendrik wrote:
Hi Panos,

missed you in Prague.

Steffen had a discussion on the focus of our CMP profile with Jim after the ACE meeting in Prague. May be we did not focus enough on industrial use cases. Our focus in not in the first place on constrained devices, but we believe that CMP would also work perfectly on all those devices capable to run TLS.
Currently CMP is already used in mobile networks and in rail networks.. But we see the need to specify the needed uses cases in more detail to get interoperable implementations.
The big advantage of CMP for industrial use is that we do not have any security requirements to the transport of the messages, since CMP messages are self-contained and support end-to-end security.  A hop-by-hop security or asynchronous transport is not always feasible.

Hendrik

Von: Panos Kampanakis (pkampana) <[e-mail]><mailto:[e-mail]>
Gesendet: Mittwoch, 8. Mai 2019 16:00
An: [e-mail]<mailto:[e-mail]>; Russ Housley <[e-mail]><mailto:[e-mail]>; Brockhaus, Hendrik (CT RDA ITS SEA-DE) <[e-mail]><mailto:[e-mail]>
Cc: Jim Schaad <[e-mail]><mailto:[e-mail]>; Fries, Steffen (CT RDA ITS) <[e-mail]><mailto:[e-mail]>
Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)


Hi Hendrik,

Long time since we talked.

With such a profile, I have a concern that what happened with SCEP, CMC, CMPv2, EST is likely to happen in constrained environments. Using two or more protocols (EST-coaps, a CMP profile over different transports, and others) that do similar things would lead to fragmentation and confuse vendors that want to pick one.

I am not sure I have heard a broad need for a CMP profile in ACE. If this is a single vendor need, does IETF even need to standardize this CMP profile?

Panos


From: Spasm <[e-mail]<mailto:[e-mail]>> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 5:10 AM
To: [e-mail]<mailto:[e-mail]>; Russ Housley <[e-mail]<mailto:[e-mail]>>
Cc: Jim Schaad <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

Hi Russ, all,

as discussed at IETF104 and on this list we would like to spend further work on updating and profiling CMP focusing on industrial use cases.
To get input, feedback and support from LAMPS we propose the following charter text.

As certificate management gets increasingly important in industrial environments, it needs to be tailored to the specific needs. CMP as existing protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be enhanced to more efficiently support of industrial use cases, crypto agility and specific communication relations on the one hand and profiled to the necessary functionality on the other hand to ease application and to better facilitate interoperable implementation.


Hendrik

Von: Russ Housley <[e-mail]<mailto:[e-mail]>>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Jim Schaad <[e-mail]<mailto:[e-mail]>>; Fries, Steffen (CT RDA ITS) <[e-mail]<mailto:steffen.fries@siemens....com>>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile

Hendrik:

The current re-charter is about two weeks away.  You would need to propose text for the charter on this list, and see if there are people that will review and implement.

Russ


On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <[e-mail]<mailto:[e-mail]>> wrote:

Hi all

Referring to the Email thread 'Seeking guidance on proceeding with question from IETF-104 presentation on lightweight CMP profile' and to the outcome of the WG meeting, we want to summarize the current state of the discussion.
The discussion we had with Jim motivate a split of the current draft into a CMP Updates and a CMP Profile document. The update of CMP is needed because we identified at least two point where a change to CMP is needed:
- Change the type of encryptedCert from EncryptedValue to EncryptedKey for ECC and post-quantum algorithm support
- Extend the RootCAUpdate announcement message to e request/response message to enable requesting the update from the client side
The remaining points from the initial email were seen as profiling topic and would therefore be handled in the CMP Profile document....

@Russ, how do you see the status of the current re-chartering process? Would you support to add both, or at least the CMP Updates, activities under the revised charter?

- Hendrik
_______________________________________________
Spasm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C6c58c593b83943837e5208d6d56cfc74%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636931061407352686&sdata=oZe2KJeg2SNLCGIaQ%2BFmdYTThejJvSAbz8OYNwfRb54%3D&reserved=0>



_______________________________________________

Spasm mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C6c58c593b83943837e5208d6d56cfc74%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636931061407352686&sdata=oZe2KJeg2SNLCGIaQ%2BFmdYTThejJvSAbz8OYNwfRb54%3D&reserved=0>
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
[OpenCA Logo]