Subject: [netconf] ssh/tls key generation support

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 22 Mar 2022 07:56:00 +0100

Hi,

Kent asked for feedback concerning key generation support. My view is
the following:

- As long as you can trust your device to generate good keys, it is
  good idea to generate keys on the device so that keys are never sent
  around and they may be kept in protected storage.

- As stated by others during the WG meeting, the proposal in
  draft-ietf-netconf-ssh-client-server-27.txt should be more explicit
  that it is about generating key pairs and in particular hostkey
  pairs.

- Generating server key pairs is just a step of a more complex
  process. In SSH, clients traditionally built trust into hostkeys
  using an ad-hoc process, in TLS this is traditionally done using
  certificates. Hence, at least for TLS, we get into the territory of
  generating certificates, either creating self-signed certs, hooking
  into an automated certification system like lets encrypt, or
  handling a full blown cert process (generating csrs etc).

- If we got the YANG modules right, then it should be possible to add
  support for server key generation without changes to the existing
  definitions (i.e., we can do this later if we decide to do so, there
  is not reason why this needs to be done now).

- The SSH and TLS documents started as WG documents in July 2016, we
  are getting close to 6 years in the WG and it is somewhat unclear
  what the uptake of these documents will be. If we get into
  certificate territory, I fear we add at least another year of delay.

My take is that we should leave key generation for future work and
instead try to deliver what we have. Note that the documents highly
interrelated and they have overall grown to a significant size (even
if we leave out the IANA algorithm registry modules, this is
substantial).

  | Pages | Lines | Draft                                            |
  |-------+-------+--------------------------------------------------|
  |    63 |  3528 | draft-ietf-netconf-crypto-types-22.txt           |
  |    51 |  2856 | draft-ietf-netconf-keystore-24.txt               |
  |    31 |  1736 | draft-ietf-netconf-http-client-server-09.txt     |
  |    60 |  3360 | draft-ietf-netconf-netconf-client-server-25.txt  |
  |    56 |  3136 | draft-ietf-netconf-restconf-client-server-25.txt |
  |   137 |  7672 | draft-ietf-netconf-ssh-client-server-27.txt      |
  |    34 |  1904 | draft-ietf-netconf-tcp-client-server-12.txt      |
  |   146 |  8176 | draft-ietf-netconf-tls-client-server-27.txt      |
  |    39 |  2184 | draft-ietf-netconf-trust-anchors-17.txt          |

/js

-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 22 Mar 2022 13:00:36 +0530

Hi WG,

I agree!

And as an author of the PCEP YANG model which is dependent on
draft-ietf-netconf-tls-client-server
<https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/>;
we would really like to see it published SOON!

Thanks!
Dhruv

On Tue, Mar 22, 2022 at 12:26 PM Jürgen Schönwälder <
[email-masked]> wrote:

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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 22 Mar 2022 18:09:44 +0000

Hi Juergen,

Thank you for your valuable comments.  More below.

Kent // author

>  around and they may be kept in protected storage.

Indeed, it is Security Best Practice 101.  It's actually shameful (to me, personally) that this work doesn't enable key-generation.  I tried so hard before and gave up only because the brick wall wasn't moving.  I see here a glimmer of hope to get back to good standing  ;)

>  that it is about generating key pairs and in particular hostkey

Easy fix, but...

>  handling a full blown cert process (generating csrs etc).

The "crypto-types" draft already defines a "generate-certificate-signing-request":

 - overview: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types#section-2.1.4.
 - example usage: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types#section-2.2.2

>  is not reason why this needs to be done now).

As presented, the SSH-based RPC is an "rpc" (not "action") statement in the "ietf-ssh-common" module (common, since sometimes NC/RC-servers need to be an SSH-client and other times an SSH-server).  Since the SSH/TLS modules only define groupings, there are no any protocol-accessible nodes to augment an "action" into later.  If added later, it would likely be via a new 4th module, something like "ietf-ssh-generate-key".  I agree, this could be done later.

>  certificate territory, I fear we add at least another year of delay.

The uptake/demand is notable.  In addition to the PCEP WG dependency, both the BBF and O-RAN are waiting for completion, and IEEE said that they're about to start looking into using.

> if we leave out the IANA algorithm registry modules, this is

Fine by me.  Less work.

>  | Pages | Lines | Draft                                            |

Please note (and I think you did already) that the SSH and TLS drafts are huge only because of the auto-generated IANA-maintained modules in the Appendix sections.  Otherwise, they are both also in the 50-page range...

> /js

K.

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 22 Mar 2022 19:33:07 +0100

>  - example usage: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types#section-2.2.2

Sectiopn 3.2 is insightful as well:

   Early revisions of this document included "rpc" statements for
   generating symmetric and asymmetric keys.  These statements were
   removed due to an inability to obtain consensus for how to identify
   the key-algorithm to use.  Thusly, the solution presented in this
   document only supports keys to be configured via an external client,
   which does not support Security best practice.

Apparently we can generate a csr but not the underlying key pair,
which indeed is half-done. Should key generation actually fall into
the crypto types module and not be TLS/SSH specific? And would that
mean that a client invoces a yet-to-define generate-key-pair rpc,
which is then followed by a generate-certificate-signing-request
action in case an explicitely signed certificate is needed? Given that
I look at these I-Ds every N months, it is somewhat of a challenge for
me to keep the context...
 
> The uptake/demand is notable.  In addition to the PCEP WG dependency, both the BBF and O-RAN are waiting for completion, and IEEE said that they're about to start looking into using.

Progress has been made in waves with a low frequency between the
waves. I do not mind to give this a final try but then there ought to
be a hard deadline - either the details have been figured out by $date
or we move ahead without this feature addressed.

/js

---

From: tom petch <[email-masked]>
Date: Wed, 23 Mar 2022 16:52:40 +0000

From: netconf <[email-masked]> on behalf of Dhruv Dhody <[email-masked]>
Sent: 22 March 2022 07:30

Hi WG,

I agree!

And as an author of the PCEP YANG model which is dependent on draft-ietf-netconf-tls-client-server<https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/>; we would really like to see it published SOON!

Dhruv

You could oppose the adoption of the NETCONF I-D that are currently up for adoption on the grounds that the WG has a backlog that is too big and has been there for too many years and should not be taking on more work until some of that backlog has passed IESG Review!

I have known ADs do just that in the past.

You also might find some allies in the Babel WG.

Tom Petch

Thanks!
Dhruv

On Tue, Mar 22, 2022 at 12:26 PM Jürgen Schönwälder <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

/js

_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf