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

[Kent Watsen <[e-mail]>]

Hi Roman,

The decision was/is to remove the mandatory attribute for when really just the private key is needed.  The fix is coming as part of the update for the AD reviews, which I stalled on due to life issues, but am about to restart.

Kent // author


> On Aug 17, 2023, at 7:34 AM, Roman Janota <Roman.Janota=[e-mail]> wrote:
> 
> Hello,
> 
> are there any updates on this? We are still wondering if the restrictions on the public-key-format leaf are necessary.
> 
> Another somewhat similar issue regarding the leaves public-key and public-key-format is them being mandatory. This makes sense for example in the ssh-server-grouping/client-authentication/public-keys container of the ietf-ssh-server YANG module, because the public key is actually used (and can not be generated from the private key, because there is none). On the other hand, in the ssh-server-grouping/server-identity/host-key/public-key (same module), the public key is most likely not going to be used, because in most cases it will be generated from the private key. Then, in this case, it would be completely fine if the leaves public-key and public-key-format were left out.
> 
> Kind regards,
> 
> Roman Janota.
> 
> On 6/14/23 11:03, Michal Vasko wrote:
>> 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]> <mailto: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: 
>>>> 
>>>> 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.)
>>>> What about the two refine constraints, lines 215-224?
>>>> Module ietf-tls-server:
>>>> 
>>>> 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.
>>>> What about 235-244?
>>>> Module ietf-ssh-client:
>>>> 
>>>> You mentioned “even for SSH/TLS client authentication”, thus the same question re: lines 171-178.
>>>> Same question re: lines 236-244.
>>>> Module ietf-tls-client:
>>>> 
>>>> Same question re: lines 214-223.
>>>> 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] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/netconf
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> netconf mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/netconf
>> 
>> 
>> _______________________________________________
>> netconf mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/netconf
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf