Re: [netconf] ietf-ssh-server host key

["Hartley, Jeff" <[e-mail]>]

Hi Michal;

Hi Kent,
Hi Michal,


Hello,

we are implementing these modules (ietf-netconf-server and imports) and I have a question regarding the container `/ietf-netconf-server:netconf-server/listen/endpoint/ssh/ssh-server-parameters/server-identity/host-key/public-key`. It looks like this

+--rw public-key
   +--rw (inline-or-keystore)
      +--:(inline) {inline-definitions-supported}?
      |  +--rw inline-definition
      |     +--rw public-key-format     identityref
      |     +--rw public-key            binary
      |     +--rw private-key-format?   identityref
      |     +--rw (private-key-type)
      |        +--:(cleartext-private-key) {cleartext-private-keys}?
      |        |  +--rw cleartext-private-key?   binary
      |        +--:(hidden-private-key) {hidden-private-keys}?
      |        |  +--rw hidden-private-key?   empty
      |        +--:(encrypted-private-key) {encrypted-private-keys}?
      |           +--rw encrypted-private-key
      |              +--rw encrypted-by
      |              +--rw encrypted-value-format    identityref
      |              +--rw encrypted-value           binary
      +--:(keystore) {central-keystore-supported,asymmetric-keys}?
         +--rw keystore-reference?   ks:asymmetric-key-ref

What is there the public key for? For a key to be used as a host key you only need the private key (technically, you can always generate the public key from the private key but the public key is not needed at all in this case) and it is causing us some problems because it is even required to be in the `ssh-public-key-format` without any information as to why. Thanks for any explanation.
You are correct, the "public-key" node typically isn't needed when configuring SSH.

The reason it is in the `SSH model is because:

1) sometimes (I forget which Security person said this) a public-key cannot be extracted from a private-key, thus a generic private-key type seems to be incomplete without its public-key encoded also.  It would be good to reconfirm this claim.

MV: That is indeed interesting and libssh nor OpenSSH sshd would probably not be able to use such a key because they expect paths to the private key when setting the host key. I must also correct myself, it really seems the tools generate the public key themselves because it is presented to the client when creating the SSH session.
2) albeit unusual, it isn't a hard thing for (my) code to encode the public-key also, so I felt it was a minor nuisance to ensure future-proofing.

MV: The problem is with the required public key formats that make it chaotic. Note that we have also defined our own identity for the private key format which corresponds to `subject-public-key-info-format` of the public key (X.509).

So for SSH:

private key format - rsa-private-key-format, ec-private-key-format (, subject-private-key-info-format)
public key format - ssh-public-key-format

And for TLS:

private key format - rsa-private-key-format, ec-private-key-format (, subject-private-key-info-format)
public key format - subject-public-key-info-format

Now, some practical information that may also be relevant.

libssh can directly work with:

private key format - rsa-private-key-format, ec-private-key-format
public key format - ssh-public-key-format

And OpenSSL can directly load:

private key format - subject-private-key-info-format
public key format - subject-public-key-info-format

We wanted to support both of these pairs for both SSH and TLS but not to mix them because it requires much more code to make it work ("manual" key creation using OpenSSL). So, SSH is fine, by default, because libssh can be used to load both private and the public key. We have encountered the problem when trying to use `subject-private-key-info-format` with `subject-public-key-info-format`, the latter was not allowed. But with TLS the problem is there already, the allowed formats are not really compatible and the private keys need to be created manually to use OpenSSL for the TLS connection.
3) thus the propagation of the asymmetric-key-pair-grouping (in crypto-types) makes it to the ssh-client-server draft.  FWIW, this is why it's named "asymmetric-key-pair-grouping" and not "private-key-grouping".

Can you say some more about why its presence is causing problems?

If this is a real problem (or perhaps even if just a nuisance), the crypto-types drafts could define also a "private-key-grouping" (having just the private-key) and then recast  "asymmetric-key-pair-grouping" to use it.  Or, if it turns out the claim (see #1) in unfounded, the  "asymmetric-key-pair-grouping" could be discarded altogether.

MV: I tried to describe the problem and I hope it can be understood. I am not saying the YANG needs to reflect the APIs of common libraries but am then wondering based on what were the restrictions of SSH and TLS public key formats added. Furthermore, there can always be new public key formats added by deriving from the provided identity and these would not be possible to use because of the must conditions. It actually seems the public key formats are restricted for all their uses (even for SSH/TLS client authentication) so new public key formats can never be used and the base identity is useless.

What would make most sense based on our experiences would be to either remove the public keys from the host key altogether or, if there really are reasons for keeping them there, lift their severe restrictions. Ideally, to only allow compatible pairs together but that would require some non-trivial modelling work. It would also be possible to remove all the conditions and let implementations decide what they exactly support because there seems to be too many options although it is always better if properly expressed in YANG. And one should never forget to allow for new future formats which cannot really be added and used, currently, at least for the public key.

JH: If I’m hearing the proposal correctly:

Module ietf-ssh-server:

  1.  We should remove the two refined constraints, lines 193-202.  This would allow for both the flexibility that Kent described, as well as reducing the strict identity constraints that you described.
I also recommend adding brief descriptive text capturing some of the above commentary, where we describe the recommended constraints as well as the intention of leaving implementers this flexibility.  i.e., where we’re unable to explicitly constrain in favor of implementation flexibility and future-proofing, we should describe usage and *intended* constraints.
(I also agree that attempting to refactor/model for every possible valid combination is a monstrous task; it would likely produce monstrous YANG.)
  2.  What about the two refine constraints, lines 215-224?

Module ietf-tls-server:

  1.  Remove the two refine constraints, lines 215-224.  Same motivation, and I’d make the same recommendation for verbose usage/constraint recommendation text in a description.
  2.  What about 235-244?

Module ietf-ssh-client:

  1.  You mentioned “even for SSH/TLS client authentication”, thus the same question re: lines 171-178.
  2.  Same question re: lines 236-244.

Module ietf-tls-client:

  1.  Same question re: lines 214-223.
  2.  Same question re: lines 234-243.

Ideally, we can apply the group’s guidance regarding these constraints and identities evenly across these similar grouping usages in both client and server modules.   I’m happy to make the edits and post them this week if the stakeholders agree upon the constraint reductions, description text, and exactly where to apply them.  (We at the BBF are eager to move forward with the client-server suite.)

Much appreciated;

-Jeff Hartley