Subject: Re: [netconf] New Version Notification for draft-ietf-netconf-sztp-csr-06.txt

From: Kent Watsen <[email-masked]>
Date: Mon, 16 Aug 2021 02:02:22 +0000

Hi Rob,

The -06 update addresses:
  - Your AD Review comments.
  - The request from the ANIMA WG to factor out some groupings.
  - An update to the description statement for the “cmc-csr” and
    “cmp-csr” nodes prompted by Security experts.
  - A number of editorial items.

The -07 update fixes an item spotted when looking at the -06 “diff”.

I believe all the issues have now been resolved.

Kent // as co-author

> On Aug 15, 2021, at 9:38 PM, [email-masked] wrote:
> 
> 
> A new version of I-D, draft-ietf-netconf-sztp-csr-06.txt
> has been successfully submitted by Kent Watsen and posted to the
> IETF repository.
> 
> Name:		draft-ietf-netconf-sztp-csr
> Revision:	06
> Title:		Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request
> Document date:	2021-08-15
> Group:		netconf
> Pages:		34
> URL:            https://www.ietf.org/archive/id/draft-ietf-netconf-sztp-csr-06.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/
> Html:           https://www.ietf.org/archive/id/draft-ietf-netconf-sztp-csr-06.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-06
> 
> Abstract:
>   This draft extends the "get-bootstrapping-data" RPC defined in RFC
>   8572 to include an optional certificate signing request (CSR),
>   enabling a bootstrapping device to additionally obtain an identity
>   certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the
>   "onboarding information" response provided in the RPC-reply.
> 
> 
> 
> 
> The IETF Secretariat
> 
>

---

From: David von Oheimb <[email-masked]>
Date: Tue, 17 Aug 2021 11:55:05 +0200

Hi Kent et al,

thanks for your message regarding the update to the draft and for
updating the CMP-related parts of the YANG module exactly as discussed.

Regarding the minor extension to the example in section 2.2, likely the
outcome of
our discussion was a bit unclear.
We agreed that the new CMP profile does not need to be referenced there.
Yet what we still suggest to do is to extend the paragraph

The SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node) containing a signed identity
certificate for the CSR provided by the SZTP-client:

as follows:

The SZTP-server validates the origin of the CSR and on success
forwards it to a backend server, which may be an RA or CA.The backend
servermust accept only legitimate CSRs approved by the SZTP-server.
Upon receiving a new identity certificate from the backend server,
the SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node) containing the identity
certificate for the CSR provided by the SZTP-client:

Regards,

    David

On 16.08.21 04:02, Kent Watsen wrote:
>> URL:            ...

---

From: Kent Watsen <[email-masked]>
Date: Tue, 17 Aug 2021 17:16:37 +0000

Hi David,

> updating the CMP-related parts of the YANG module exactly as discussed.
Not *exact*, as Sean tweaked CMC Case 2 (removing the controlSequence restriction and adding a new final sentence) and CMC Case 3 (removing the controlSequence restriction X2).

> Regarding the minor extension to the example in section 2.2, likely the outcome of
> forwards it to a backend server, which may be an RA or CA. The backend
> server must accept only legitimate CSRs approved by the SZTP-server.

I’m unsure if this is a good addition because nowhere, except in the Security Considerations section, is there any discussion about a backend CA.  Of course it is the most likely scenario, but it could also be the case that the CA has the SZTP-server functionality embedded.  

Additionally, whilst not a bad idea for the SZTP-server to validate the CSR, it seems even more important that the CA be able to do so without taking the SZTP-server’s word for it - right?   Note: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-07#section-4.2.1 <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-07#section-4.2.1>.

PS: currently the draft just says “CA”.  Do you think it should say “CA or RA” instead?

Thanks,
Kent

---

From: David von Oheimb <[email-masked]>
Date: Wed, 18 Aug 2021 08:17:19 +0200

Hi Kent,

> Not *exact*, as Sean tweaked CMC Case 2 (removing the controlSequence
> restriction and adding a new final sentence) and CMC Case 3 (removing
> the controlSequence restriction X2).

I did not have a look at other portions of the draft, such as those you
mention here regarding CMC. Our focus is CMP.

> I’m unsure if this is a good addition because nowhere, except in the
> Security Considerations section, is there any discussion about a
> backend CA.
> Of course it is the most likely scenario, but it could also be the
> case that the CA has the SZTP-server functionality embedded.

That's right. Though one could argue that the text in section 2.2 is
"just" on example usage, here is a generalization:

After the origin of the CSR and the included proof-of-possession
have been validated successfully and the CSR has been approved,
the SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node) containing the identity
certificate for the CSR provided by the SZTP-client:

>
> Additionally, whilst not a bad idea for the SZTP-server to validate
> the CSR, it seems even more important that the CA be able to do so
> without taking the SZTP-server’s word for it - right?  
> Note: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-07#section-4.2.1
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-sztp-csr-07%23section-4.2.1&data=04%7C01%7C3fc86e35-ce5e-4719-beb0-5253a4681d60%40ad011.siemens.com%7C5d5f558cf6a2486246f208d961a2c6d5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637648174597329906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZMNCeGufDpd44ApBYJ1SW2TtgZ%2BpBGm0XQfqQ6NZwhY%3D&reserved=0>.
>

Good point that the checks should be mentioned (also) in the security
considerations,
and indeed just mentioning "CA" is not general enough.

Here is a couple of suggested text improvements:

4.1.5
<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-07#section-4.1.5>.
Selecting the Best Origin Authentication Mechanism

old:

   When generating a new key, it is important that the client be able to
   provide additional proof to the CA that it was the entity that
   generated the key.

new:

   When generating a new key, it is important that the client be able to
   provide additional proof that it was the entity that generated the key.
   This should be verified successfully before issuing the certificate.

old:

4.2.1
<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-07#section-4.2.1>.
Conveying Proof of Possession to a CA

new:

4.2.1
<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-07#section-4.2.1>.
Conveying Proof of Possession

old:

   When the bootstrapping device's manufacturer-generated private key
   (e.g., the IDevID key) is reused, a CA may validate that the CSR was
   signed by that key.

new:

   When the bootstrapping device's manufacturer-generated private key
   (e.g., the IDevID key) is reused, verifying the proof-of-possession
   validates that the CSR was signed by that key.

old:

   Both the CMP and CMC formats entail the bootstrapping device signing
   the request once with its (e.g., LDevID) key and then again with its
   (e.g., IDevID) key, which enables a downstream CA to be assured that
   the bootstrapping device possesses the public key being signed.

new:

   Both the CMP and CMC formats entail that the bootstrapping device signs
   the request once with its (e.g., LDevID) key and then again with its
   (e.g., IDevID) key. This enables verifying the proof-of-possession
   of the private key that corresponds to the public key being signed.

    David

---

From: Kent Watsen <[email-masked]>
Date: Tue, 24 Aug 2021 14:54:00 +0000

Hi David,

I took all your suggestions into account.   I reworded things so, please review the diffs.  Here’s the direct link to the diffs:

	https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-08.txt <https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-08.txt>

Thanks again,
Kent

> On Aug 18, 2021, at 2:17 AM, David von Oheimb <[email-masked]> wrote:
> 
> Hi Kent,
> 
> I did not have a look at other portions of the draft, such as those you mention here regarding CMC. Our focus is CMP.
> 
> 
> 
>> I’m unsure if this is a good addition because nowhere, except in the Security Considerations section, is there any discussion about a backend CA.
>> Of course it is the most likely scenario, but it could also be the case that the CA has the SZTP-server functionality embedded. 
> That's right. Though one could argue that the text in section 2.2 is "just" on example usage, here is a generalization:
> 
>> Additionally, whilst not a bad idea for the SZTP-server to validate the CSR, it seems even more important that the CA be able to do so without taking the SZTP-server’s word for it - right?   Note: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-07#section-4.2.1 <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-sztp-csr-07%23section-4.2.1&data=04%7C01%7C3fc86e35-ce5e-4719-beb0-5253a4681d60%40ad011.siemens.com%7C5d5f558cf6a2486246f208d961a2c6d5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637648174597329906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZMNCeGufDpd44ApBYJ1SW2TtgZ%2BpBGm0XQfqQ6NZwhY%3D&reserved=0>.
>> 
> Good point that the checks should be mentioned (also) in the security considerations,
> 4.1.5 <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-07#section-4.1.5>.  Selecting the Best Origin Authentication Mechanism
> 
> old:
> 
> 4.2.1 <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-07#section-4.2.1>.  Conveying Proof of Possession to a CA
> 
> new:
> 
> 4.2.1 <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-07#section-4.2.1>.  Conveying Proof of Possession
> old:
>

---

From: David von Oheimb <[email-masked]>
Date: Mon, 30 Aug 2021 10:28:44 +0200

Hi Kent,

thanks for your update and providing the diff.
I had a closer look at sections 4.1.5 and 4.2.1 and found some further
issues.

  * Section 4.1.5 - since correct identity of the request origin is
    *crucial* for any type of identity cert generation:

old:

A The CSR's origin SHOULD be verified before a certificate is issued.

new: 

The origin of the CSR MUST be verified before a certificate is issued.

  * Section 4.2.1 - actually, a proof-of-possession can and should be
    done in all addressed situations,
    while for PKCS#10 it is hard to link this to a proof-of-origin.

old:

When the bootstrapping device's manufacturer-generated private key   
 (e.g., the IDevID key) is reused for the CSR, proof-of-possession is   
verified by ensuring the CSR was signed by that key.  

When a new asymmetric key is used, proof-of-possession may be   
verified, with the CMP or CMC formats, by ensuring the parent ASN.1   
structure containing the CSR is signed by the manufacturer-generated
key.   

new:

Since the CSR should have been self-signed using the private key
corresponding to the public key placed in the CSR, the proof-of-possession
can be checked by verifying this signature using the included public key.

With the CMP or CMC formats, this proof-of-origin is directly linked to the
proof-or-origin provided by the parent ASN.1 structure, which contains
origin authentication using the manufacturer-generated private key or using
the shared secret.

Regards,

    David

On 24.08.21 16:54, Kent Watsen wrote:
> Hi David,
>
> I took all your suggestions into account.   I reworded things so,
> please review the diffs.  Here’s the direct link to the diffs:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-08.txt
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-netconf-sztp-csr-08.txt&data=04%7C01%7C3fc86e35-ce5e-4719-beb0-5253a4681d60%40ad011.siemens.com%7C463fd9900eff453729ce08d9670f029f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637654137164261161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=SQ4rPsrPMS9gv47CLaoztO6sTZrC3PHc4IsfjxUSSkE%3D&reserved=0>
>
> Thanks again,
> Kent
>
>
>
>> On Aug 18, 2021, at 2:17 AM, David von Oheimb
>> <[email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>> Hi Kent,
>>
>>> Not *exact*, as Sean tweaked CMC Case 2 (removing the
>>> controlSequence restriction and adding a new final sentence) and CMC
>>> Case 3 (removing the controlSequence restriction X2).
>>
>> I did not have a look at other portions of the draft, such as those
>> you mention here regarding CMC. Our focus is CMP.
>>
>>
>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-sztp-csr-07%23section-4.2.1&data=04%7C01%7C3fc86e35-ce5e-4719-beb0-5253a4681d60%40ad011.siemens.com%7C463fd9900eff453729ce08d9670f029f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637654137164261161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=VnaB1XiuUSaF1wcBZ%2By26h2%2FlwSM06Zq%2BIusXrZxADs%3D&reserved=0>.
>>>
>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-sztp-csr-07%23section-4.1.5&data=04%7C01%7C3fc86e35-ce5e-4719-beb0-5253a4681d60%40ad011.siemens.com%7C463fd9900eff453729ce08d9670f029f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637654137164271116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=9gdOH%2BpT7OZE0rMONzXQOw3OGIvVxqjGttNmeBEtMOg%3D&reserved=0>.
>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-sztp-csr-07%23section-4.2.1&data=04%7C01%7C3fc86e35-ce5e-4719-beb0-5253a4681d60%40ad011.siemens.com%7C463fd9900eff453729ce08d9670f029f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637654137164271116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=xdntWnemJfdC1%2FJuFzHhgJQH8GAlHVWB5UjdhzzW9vQ%3D&reserved=0>.
>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netconf-sztp-csr-07%23section-4.2.1&data=04%7C01%7C3fc86e35-ce5e-4719-beb0-5253a4681d60%40ad011.siemens.com%7C463fd9900eff453729ce08d9670f029f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637654137164271116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=xdntWnemJfdC1%2FJuFzHhgJQH8GAlHVWB5UjdhzzW9vQ%3D&reserved=0>.

---

From: Kent Watsen <[email-masked]>
Date: Mon, 30 Aug 2021 15:58:23 +0000

Hi David,

> I had a closer look at sections 4.1.5 and 4.2.1 and found some further issues.
> 
> 
> 
> Section 4.1.5 - since correct identity of the request origin is crucial for any type of identity cert generation:
> old:
> 

Ack.  

Perhaps replace “MUST” with “must”, since the behavior is normatively defined by other documents? 

> Section 4.2.1 - actually, a proof-of-possession can and should be done in all addressed situations,
> structure containing the CSR is signed by the manufacturer-generated key.    
> 
> new:
> 

The current section is titled "Verifying Proof of Possession”.  I think that new “proof of origin" text should go into a new section called "Verifying Proof of Origin”.  Something like this:

	Verifying Proof of Possession

	Regardless if using a new asymmetric key or the bootstrapping
	device's manufacturer-generated key (e.g., the IDevID key), the
	public key is placed in the CSR and the CSR is signed by that
	private key.  Proof-of-possession of the private key is verified
	by ensuring the signature over the CSR using the public key
	placed in the CSR.

	Verifying Proof of Origin

	When the bootstrapping device's manufacturer-generated 
	private key (e.g., the IDevID key) is reused for the CSR, 
	proof-of-origin is verified by ensuring the CSR was signed
	by that key.   

	When a new asymmetric key is used, proof-or-origin is
	provided, in the CMP and CMC formats, by the CSR’s
	parent ASN.1 structure containing origin authentication
	using either the manufacturer-generated private key or
	a shared secret.

Thoughts?

K.