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

[Michal Vasko <[e-mail]>]

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.

Regards,
Michal