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

[Roman Janota <[e-mail]>]

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]> 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
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf