Subject: [lamps] Seeking guidance on proceeding with question from IETF-104 presentation on lightweight CMP profile

From: "Fries, Steffen" <[email-masked]>
Date: Tue, 2 Apr 2019 05:12:15 +0000

Hi,

during the LAMPS session in IETF-104 we presented a draft for a lightweight industrial CMP profile. The document as such bases on CMP and targets to simplify the very versatile CMP. 

During the presentation we have been asked to also talk to the ACE WG chair regarding potential interest in this work, as it was not sure if LAMPS is the right home. I talked to Jim Schaad and as we only work on CMP directly, not with the transport nor specific considerations for constraint devices, ACE may not be the right home. Also, Jim was asking if the draft needs to be a standards track RFC and thus be adopted in a WG. An alternative approach could also be an independent submission. To make this decision, we need some guidance. 

For this, let me enumerate the main points we addressed in the draft:
- Generally Section 1.4 enlists the exceptions from the mandatory CMP Profile as defined in RFC4210 Appendix D:
 o  signature-based protection is the default protection; initial transactions may also use HMAC,
 o  certification of a second key pair within the same transaction is not supported,
 o  proof-of-possession (POPO) with self-signature of the certTemplate according to [RFC4211] section 4.1 clause 3 is the only supported POPO  method,
 o  confirmation of newly enrolled certificates may be omitted, and especially
 o  all transactions consist of request-response message pairs originating at the end entity (EE), i.e., announcement messages are omitted.
- In section 4.1.5 the proceeding of central key generation needed extensions at least for ECC key pairs.
- In section 4.4.1 the RootCAUpdate is specified as request-response transaction and differs from the announcement message as specified in RFC4210 section 4.4 and Appendix E.
- In section 5 the new Extended Key Usages id-kp-cmpRA is introduced to indicate that a key pair is entitled to be used by an LRA/RA for signature-based protection of a CMP message.
- Generally further topics to clarify CMP or CRMF may come up during WG review.

Based on this list, are these point to be handled as profiling of the base protocol or are they rather seen as technical change/enhancement? 
My understanding is that for profiling an independent RFC would be fine, as the base spec can be normatively referenced by other standards. In this case the CMP profile document can be informational. 
If some of the points listed qualify rather for technical changes of the base protocol, my understanding is that we need to find a home for the draft and target the standard track. @Jim, I hope my conclusion based on our conversation is right.

Regarding interest in the resulting RFC there is work ongoing in ANIMA WG and EAP WG, that can directly leverage the lightweight CMP.

In either case your view is appreciated.

Best regards
Steffen

---

From: Jim Schaad <[email-masked]>
Date: Tue, 2 Apr 2019 11:57:30 -0700

This is a quick walk through what you have below.  It would have been
helpful to have pointers to the sections/bullet points where things are
meant to be modified.

> -----Original Message-----
> From: Spasm <[email-masked]> On Behalf Of Fries, Steffen
> Sent: Monday, April 1, 2019 10:12 PM
> To: [email-masked]
> Subject: [lamps] Seeking guidance on proceeding with question from IETF-
> 104 presentation on lightweight CMP profile
> 
> 
> Hi,
> 
> during the LAMPS session in IETF-104 we presented a draft for a
lightweight
> industrial CMP profile. The document as such bases on CMP and targets to
> simplify the very versatile CMP.
> 
> During the presentation we have been asked to also talk to the ACE WG
chair
> regarding potential interest in this work, as it was not sure if LAMPS is
the
> right home. I talked to Jim Schaad and as we only work on CMP directly,
not
> with the transport nor specific considerations for constraint devices, ACE
may
> not be the right home. Also, Jim was asking if the draft needs to be a
> standards track RFC and thus be adopted in a WG. An alternative approach
> could also be an independent submission. To make this decision, we need
> some guidance.
> 
> - Generally Section 1.4 enlists the exceptions from the mandatory CMP
> Profile as defined in RFC4210 Appendix D:

Depending on what is being proven this is reasonable.  I would consider this
to be profiling

> o  certification of a second key pair within the same transaction is not
supported,  

I would consider this to be profiling

> o  proof-of-possession (POPO) with self-signature of the certTemplate
according to [RFC4211] section 4.1 clause 3 is the only supported POPO
method, 

I would consider this to be profiling

> o  confirmation of newly enrolled certificates may be omitted, and
especially  

I would consider this to be profiling

> o  all transactions consist of request-response message pairs originating
at the end entity (EE), i.e.,  announcement messages are omitted.

I would consider this to be profiling

> extensions at least for ECC key pairs.

Not sure what you think falls here and the document is not forth coming.
This may have already been done.

> - In section 4.4.1 the RootCAUpdate is specified as request-response
> transaction and differs from the announcement message as specified in
> RFC4210 section 4.4 and Appendix E.

Depending on how this is done, it will require an update of RFC 4211.  I
believe that this means it must be an IETF consensus document and may need
to be standards track.

> - In section 5 the new Extended Key Usages id-kp-cmpRA is introduced to
> indicate that a key pair is entitled to be used by an LRA/RA for
signature-
> based protection of a CMP message.

This can be considered to be a profile.

> Based on this list, are these point to be handled as profiling of the base
> protocol or are they rather seen as technical change/enhancement?
> My understanding is that for profiling an independent RFC would be fine,
as
> the base spec can be normatively referenced by other standards. In this
case
> the CMP profile document can be informational.
> If some of the points listed qualify rather for technical changes of the
base
> protocol, my understanding is that we need to find a home for the draft
and
> target the standard track. @Jim, I hope my conclusion based on our
> conversation is right.
> 
> Regarding interest in the resulting RFC there is work ongoing in ANIMA WG
> and EAP WG, that can directly leverage the lightweight CMP.

Have either of these groups expressed any active interest in this work?
This is not something that EAP would normally be looking at as far as I know
as they normally consider the act of setting up the EAP credentials to be a
"Not My Problem" space.  

Jim

> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 3 Apr 2019 16:11:48 +0000

Hi Jim, 
> This is a quick walk through what you have below.  It would have been helpful to have pointers to the sections/bullet points where
> things are meant to be modified.
First of all, thank you for the walk through. I made some comments to your questions. 

> > industrial CMP profile. The document as such bases on CMP and targets
> > to simplify the very versatile CMP.
> >
> > standards track RFC and thus be adopted in a WG. An alternative
> > approach could also be an independent submission. To make this
> > decision, we need some guidance.
> >
> Depending on what is being proven this is reasonable.  I would consider this to be profiling
> 
> > o  certification of a second key pair within the same transaction is
> > not
> supported,
> 
> according to [RFC4211] section 4.1 clause 3 is the only supported POPO method,
> 
Our understanding was that the current approach in RFC 4210 requires at least some support for RSA even if the generated key pair is ECDSA. This is due to the statement for encrypting the private key when sending the generated material back to the client. Here, the encryption key is to be encrypted with a short term asymmetric key of the client. 

> Depending on how this is done, it will require an update of RFC 4211.  I believe that this means it must be an IETF consensus document
> and may need to be standards track.
The intention here was to avoid the announce messages for the RootCA update completely to better support application in constraint devices, which may be temporarily offline or my not feature a server part listening for announce messages. Using a request response allows the client to simply ask for an update. 
Why do you think this will influence also RFC 4211?

> 
> > - In section 5 the new Extended Key Usages id-kp-cmpRA is introduced
> > to indicate that a key pair is entitled to be used by an LRA/RA for
> signature-
> > Based on this list, are these point to be handled as profiling of the
> > base protocol or are they rather seen as technical change/enhancement?
> > Regarding interest in the resulting RFC there is work ongoing in ANIMA
> > WG and EAP WG, that can directly leverage the lightweight CMP.
> 
> This is not something that EAP would normally be looking at as far as I know as they normally consider the act of setting up the EAP
> credentials to be a "Not My Problem" space.
Both groups are not active regarding CMP adaptation to my knowledge. But there are documents discussed (currently individual submissions and not WG items), which can leverage a lightweight CMP without the need of specifying something by their own. 
In EAP draft-pala-eap-creds targets enrollment over EAP and specifically addresses CMP. We also talked to Max (the author) and he is interested in utilizing a lightweight CMP for this. 
In ANIMA, we proposed BRSKI-AE to allow for enrollment in domains, which are not always online or which do not feature an on-site PKI. Here, self-contained objects are necessary to bind the initial authentication of an enrolling device to the certification request directly, instead of binding it to the underlying transport protocol. CMP would be applicable as one option for providing such a self-contained object. 

Best regards
Steffen

---

From: Jim Schaad <[email-masked]>
Date: Wed, 3 Apr 2019 11:26:28 -0700

> Sent: Wednesday, April 3, 2019 9:12 AM
> To: Jim Schaad <[email-masked]>; [email-masked]
> Subject: Re: [lamps] Seeking guidance on proceeding with question from
> IETF-104 presentation on lightweight CMP profile
> 
> Hi Jim,
> > > industrial CMP profile. The document as such bases on CMP and
> > > targets to simplify the very versatile CMP.
> > >
> > > not be the right home. Also, Jim was asking if the draft needs to be
> > > a standards track RFC and thus be adopted in a WG. An alternative
> > > - Generally Section 1.4 enlists the exceptions from the mandatory
> > > CMP Profile as defined in RFC4210 Appendix D:
> Our understanding was that the current approach in RFC 4210 requires at
> least some support for RSA even if the generated key pair is ECDSA. This
is
> due to the statement for encrypting the private key when sending the
> generated material back to the client. Here, the encryption key is to be
> encrypted with a short term asymmetric key of the client.

Profiling to use EncryptedKey rather than EncryptedValue would deal with
this issue.  It would also provide all of the other good things that might
show up in the future such as quantum crypto as they would be done for the
CMS work.  This would not change any existing implementations that are still
RSA.

> > Depending on how this is done, it will require an update of RFC 4211.
> > I believe that this means it must be an IETF consensus document and may
> need to be standards track.
> The intention here was to avoid the announce messages for the RootCA
> update completely to better support application in constraint devices,
which
> may be temporarily offline or my not feature a server part listening for
> announce messages. Using a request response allows the client to simply
ask
> for an update.

Typo - I think of RFC4210 and RFC 4211 as being together and had both open.
I meant to type RFC 4210.

I am not sure how much this is needed depending on how often this is used
and why you think this is needed.  If you have a directory or similar then
pointers to where they can be found.

> > > Based on this list, are these point to be handled as profiling of
> > > the base protocol or are they rather seen as technical
> change/enhancement?
> > > Regarding interest in the resulting RFC there is work ongoing in
> > > ANIMA WG and EAP WG, that can directly leverage the lightweight CMP.
> >
> > This is not something that EAP would normally be looking at as far as
> > I know as they normally consider the act of setting up the EAP
credentials
> to be a "Not My Problem" space.
> Both groups are not active regarding CMP adaptation to my knowledge. But
> there are documents discussed (currently individual submissions and not WG
> items), which can leverage a lightweight CMP without the need of
specifying
> something by their own.
> In EAP draft-pala-eap-creds targets enrollment over EAP and specifically
> addresses CMP. We also talked to Max (the author) and he is interested in
> utilizing a lightweight CMP for this.
> In ANIMA, we proposed BRSKI-AE to allow for enrollment in domains, which
> are not always online or which do not feature an on-site PKI. Here, self-
> contained objects are necessary to bind the initial authentication of an
> enrolling device to the certification request directly, instead of binding
it to
> the underlying transport protocol. CMP would be applicable as one option
for
> providing such a self-contained object.

Ok - I was just making sure it was real.  I don't remember the draft from
Max.

Jim

---

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 3 Apr 2019 19:05:52 +0000

> On 3. Apr 2019, at 20:26, Jim Schaad <[email-masked]> wrote:
> 
> 
> 

That is a nice approach not requiring own additions and using what is already there. Much appreciated.

> pointers to where they can be found.
We just wanted to avoid that a client has to listen for the announce messages. Pointing to a directory would then be out of the definition from CMP and rather a client side configuration? Yes, this could be done. Alternatively the CMP request/response may be used.
> Ok - I was just making sure it was real.  I don't remember the draft from
We had some conversation with Max regarding the profiling and he was in favor as it eases the application over EAP to only the necessary exchanges.

Best regards
Steffen