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

[Kent Watsen <[e-mail]>]

Hi Michal,

As I’m about to push an update to Datatracker, I find myself coming back to this message with questions…

Kent





> On Jun 5, 2023, at 10:27 AM, Michal Vasko <mvasko=[e-mail]> wrote:

<snip/>
> 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
> 
Why did you create "subject-private-key-info-format”?
Is there an ASN.1 for it?  
I thought that the drafts supported everything...



> 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
> 
OpenSSL can NOT directly load rsa-private-key-format, ec-private-key-format...?
  - I’m sure I’ve tested this…

OpenSSL can directly load "subject-private-key-info-format”…?
  - How does this key get created?


> 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.
> 
Can you provide references to where in the YANG your issues arise?   

Specifically, I don’t see any reference to the "private-key-format” base identity that prevents the creation of new derived private-key identities...



>> 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.
> 
They were added for obvious reason that it makes no sense to pass a SSH/TLS key-format into a TLS/SSH library.

> 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.
> 
This seems overstated.  
RFC 7950 says "A ‘must' statement may be removed or its constraint relaxed.”
If a new format is defined, then the ‘must’ statements can be adjusted to accommodate it.

> 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.
> 

I have done this so far:

1) in crypto-types, made the public-key parts of asymmetric-key-pair-grouping “mandatory false”.

2) in ietf-[ssh/tls]-client.yang, updated ‘client-identity’ must-expressions to not require the public-key parts to be present but, if they are, they must be the right format.

3) in ietf-[ssh/tls]-server.yang, updated ’server-identity’ must-expressions to not require the public-key parts to be present but, if they are, they must be the right format.

> Regards,
> Michal
> 

Kent