Subject: [lamps] CMP draft WGLC: measuring entropy, CA certificates

From: "Salz, Rich" <[email-masked]>
Date: Fri, 19 Nov 2021 19:06:02 +0000

Top of page 25, “the entropy of the shared secret information SHALL NOT be less than the security strength of the centrally generated key pair.”  This construct also appears a couple of others times. How do you measure the entropy so that you can do the comparison?

Was the ability to send trust anchors as part of *any* CMP response discussed?  I missed the last couple of WG meetings, so I’m not sure. Why is it part of general response, rather than a response to a specific EE request?

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 22 Nov 2021 08:02:53 +0000

Rich

Thank you for your feedback.

> Top of page 25, “the entropy of the shared secret information SHALL NOT be less than the security strength of the centrally generated key pair.”

> This construct also appears a couple of others times. How do you measure the entropy so that you can do the comparison?

Measuring the entropy of a shared secret information is possible when generating it, as long as you know the quality of the random number generator. In a managed environment, the intended length of keys is known. Therefore, it should be possible providing sufficient entropy when generating a shared secret information for protection of a centrally generated key pair.
Of course, if you do not know in advance what the shared secret information will be used for, it is hard to decide which strength is adequate. Then my advice would be choosing a rather high entropy, to be on the safe side.

> Was the ability to send trust anchors as part of *any* CMP response discussed?

> I missed the last couple of WG meetings, so I’m not sure.

> Why is it part of general response, rather than a response to a specific EE request?

First of all, I would like to give some background on trust anchor provisioning using CMP.
Sending trust anchors is already part of RFC 2510 and RFC 4210 using caPubs in any CertRepMessage. RFC4210 is rather unspecific on when and how using it. There is also no security consideration on providing trust anchors in RFC 4210 today.

LTE (133310v15.1.0) is even more unspecific saying that the operator root certificate may be provided in extraCerts, which is unprotected.:
Section 9.5.1
- If the base station is not pre-provisioned with the operator root CA certificate, then the base station shall take the
operator root certificate from the certificates received in the initialization response. The selection shall be based
on checking which root certificate can be used to validate the received base station certificate.
Section 9.5.4.3
The extraCerts field of the PKIMessage carrying the initialization response shall be mandatory and shall contain the
operator root certificate and the RA/CA certificate (or certificates if separate private keys are used for signing of
certificates and CMP messages). If the RA/CA certificate(s) are not signed by the operator root CA, also the
intermediate certificates for the chain(s) up to the operator root certificate shall be included in the extraCerts field.

UNISIG (Subset-137 V1.0) only says that caPubs shall be used.
Section 6.3.2.4.1
caPubs 1..MAX   Optional              Shall be used

We add guidance on providing trust anchor already back in draft-brockhaus-lamps-lightweight-cmp-profile and further developed the text. With the updates submitted for IETF 112 we consolidated such security considerations in CMP Updates updating the Security Considerations of RFC 4210, as they are not specific to the Lightweight CMP Profile.

In managed environments, the RA is often part of the device management on site. Such device management typically configures trust anchor a device shall use. It was discussed among the authors to also use CMP general message to securely enroll such trust anchor to the devices. We proposed opening the scope of id-it-caCerts general message to provide root CA certificates next to other CA certificates on the mailing list in thread “Generalizing the CMP "Get CA certificates" use case”.  To address the special criticality of providing trust anchors using CMP we added the security consideration.

I hope this explain the history and our intend of this change. Any suggestions on improving the text is welcome.

Hendrik

Von: Spasm <[email-masked]> Im Auftrag von Salz, Rich
Gesendet: Freitag, 19. November 2021 20:06
An: [email-masked]
Betreff: [lamps] CMP draft WGLC: measuring entropy, CA certificates