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

[Michal Vasko <[e-mail]>]

Hi Kent, Jeff,

I am in no way a security of SSH expert, mostly just a user of 
cryptographic libraries so I am fine with keeping both the private and 
public key nodes in the module. Making the public key optional would be 
helpful for us, though.

As for removing all the must conditions, I definitely support that as it 
will allow some format pairs that we want to use but are forbidden. 
Regarding all the places where they could be removed, when talking about 
client authentication I was still referring to the server configuration, 
specifically YANG ietf-ssh-server lines 281 - 291, so I think all of 
those could be removed and perhaps mention that some implementations may 
not support all the combinations of public-private key formats, not sure 
how to solve this exactly. Also, I have yet to hear any justification 
for all those must conditions in the form they are now present in the 
modules.

Regards,
Michal

On 13. 6. 2023 22:56, Kent Watsen wrote:
> [Top-posting as my comment isn't line-specific]
>
> Thanks Jeff.
>
> The heart of the issue (IMO) is that the crypto-types module requires 
> each instance of the "asymmetric-key-pair-grouping" to specify the 
> public-key (unexpected) and the private-key (expected).
>
> Some suggest the public-key doesn't have to be specified, as it can 
> always be extracted from the private-key.  But this assumes that 
> access to the private key is given, which may not be the case if the 
> private-key is:
>
>    1) restricted by access-control (e.g., NACM)
>    2) encrypted-by another key
>    3) or hidden by the system.
>
> Yet the public-key is needed in order to encrypt a message using it.   
> Other groupings (see keystore draft) enable X.509 certs to be 
> configured on a per asymmetric-key-pair basis, and there are examples 
> showing this being done for a "hidden" key (think a TPM-protected IDevID).
>
> So regardless if a public-key can or cannot be extracted from a 
> private-key, there are other reasons for why having the public-key 
> present is desirable.  The issue seems to teeter on if it MUST or MAY 
> be present.
>
> In YANG, we could convert this:
>
>   grouping asymmetric-key-pair-grouping {
>     uses public-key-grouping;
>     ...
>   }
>
> To this:
>
>   grouping asymmetric-key-pair-grouping {
>     uses public-key-grouping {
>       refine "public-key-format" {
>             mandatory false;
>           }
>       refine "public-key" {
>             mandatory false;
>           }
>       }
>     }
>     ...
>   }
>
> And then deal with the resulting fallout, e.g., refinements made in 
> the SSH/TLS modules anticipating that the public-key must exist, 
> essentially the part that Jeff's response focused on.
>
> Thoughts?
>
> PS: Rich Salz (from Security area) agreed to review this issue 
> sometime before next week.
>
> Kent  // author-hat
>
>
>
>
>> On Jun 13, 2023, at 11:16 AM, Hartley, Jeff 
>> <Jeff.Hartley=[e-mail]> wrote:
>>
>> 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:
>>
>>  3. 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.
>>  4. What about 235-244?
>>
>> Module ietf-ssh-client:
>>
>>  5. You mentioned “even for SSH/TLS client authentication”, thus the
>>     same question re: lines 171-178.
>>  6. Same question re: lines 236-244.
>>
>> Module ietf-tls-client:
>>
>>  7. Same question re: lines 214-223.
>>  8. 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
>>
>> _______________________________________________
>> netconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netconf
>
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf