In case of multiple Hiba certs on server side which one should be used for hiba check

[rohit21187]

Hi Team,
Servers can have multiple hostkeys with different algorithms(rsa, ed25519,ecdsa etc). Similarly multiple server(host) certs for each algorithms can be imported to be used in host key validation.

In case of multiple certs on same host (assuming all have same hiba extensions) which algorithms should be priotised for client certificates hiba extension validation.

Should it be based on sshd_config which HostCertificate entry comes first.

(if all host certs have same extension using anyone should pass but if we have a documentation around it, that will be great)

[morrowc]

Hey there, I'm going to bet that the best person to answer this is @sourcequench ... but i'm willing to take a swing at the ball.

I had always understood and expected HIBA extensions to only really make sense in the CLIENT part of the conversation.
SO really a server can have, more than one key / cert, ie:

$ cat /etc/ssh/sshd_config | egrep 'HostKey|HostCert'
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

And a client may have many keys / certs:

~$ ssh-add -l
256 SHA256:<THINGS WERE HERE>VHpkaM morrowc@morrowc (ED25519)
256 SHA256:<THINGS WERE HERE>5VPO/Rk morrowc@morrowc (ED25519)
256 SHA256:<THINGS WERE HERE>1okLg morrowc@morrow (ED25519)
256 SHA256:<THINGS WERE HERE>foQhZIiUSKI publickey (ECDSA)
256 SHA256:<THINGS WERE HERE>oxpopcmKE morrowc (ECDSA-CERT)
256 SHA256<THINGS WERE HERE>EfMtLGQqzMnQ morrowc (ECDSA-CERT)

It may be that one of those -CERT values has some HIBA extensions attached.
I don't expect we ever see HIBA extensions on the SERVER side, though... I don't know how a client would evaluate that data, there's not a path to extract and decide on them at the client side.

[sourcequench]

Ok, I got confused for a bit, but this now makes sense to me. Yes there could be multiple certificates on the device, but the hiba-chk binary points at one of them. It is up to your use of hiba-chk which one you use. For example:

/usr/sbin/hiba-chk -i /etc/ssh/ssh_host_dsa_key-cert.pub -g /etc/ssh/hiba.grl -r %u %k

https://github.com/google/hiba/blob/main/INSTALL.md#configuration

It is the client side that would be validating host certificates - although I'm sure hiba-chk itself makes sure that the certificate is valid.

[rohit21187]

Agreed @sourcequench -i should be taken as source for configration.

https://github.com/openconfig/gnsi/blob/main/credentialz/cred-hiba-check-api-spec.md this is what I was looking for.
The file states that -i

I want clarity on a few scenario's

1. When hiba tool enable and server rotation both are in same rpc?
   -> last cert in the rpc will be in -i in caseof multiple certs.

2. Certs already rotated in a previous rpc now hiba is enabled ?
   Do we need to maintain a file which cert was rotated last what happens in case ?

3. hiba has a -i (and multiple certs are present on the host) now only one of the host certificate is updated (say not the one in -i) ?
   -> new cert should replace in -i as per the md file

[sourcequench]

I see, yes, I agree that we have a repeated AuthenticationArtifacts message so we could have multiple certificates, but just enabling the hiba-chk tool is insufficient to say which certificate to use. I don't really understand the cred-hiba-check-api-spec.md document and I agree that "the last certificate provided will be used for this mapping" is not great and it would be better to be explicit. Given that API v1.0 specification it'd be the responsibility of the caller to make sure that the "last" certificate in the repeated AuthenticationArtifacts provided is the one to be used by hiba-chk. So if that is the API v1.0 then that is what we should do - it is functional but not terrific that the order of AuthenticationArtifacts can have an operational impact on the tool used. I guess what would you like to see here would be my question - we could update the proto, but this should be at least functional and allow for implementation now. I question how common in the real world multiple certificates is a common thing. Even in a world of regularly updating short-lived host certificates I would expect a single Host Certificate would be the most common anyway. That does not mean that every HostKey needs to have a certificate. If clients are configured to require host key validation and they have the @cert-authority the server will hand back all the host keys and certificates and strict verification would work fine even if not every host key was signed.

[rohit21187]

Yes a proto for which certificate is to be used for hiba will be great.
I agree mostly each server will have one host certificate. But I see a case of fips where we might require two certs as mostly people have ed25519 (for its advantages) and rsa/ecdsa if some nodes require fips complaince. I agree that case too can be handled via only a fips complaint cert on that node.

The question now i have until we come up with a proto is how to populate the -i <> in hiba check in case of multiple or even a single cert.
As i see we do not like the current "the last certificate provided will be used for this mapping".
@sourcequench

[rohit21187]

@sourcequench @morrowc