Bug 2087915
| Summary: | ssh-ed25519 and sk-ssh-ed25519 hostkeyalgorithms supported in FIPS | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Ondrej Moriš <omoris> |
| Component: | openssh | Assignee: | Dmitry Belyavskiy <dbelyavs> |
| Status: | CLOSED ERRATA | QA Contact: | Ondrej Moriš <omoris> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9.0 | CC: | asosedki, jjelen, mhavrila |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-11-15 11:21:51 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Deadline: | 2022-07-25 | ||
|
Description
Ondrej Moriš
2022-05-18 14:23:49 UTC
This looks to me like a dupplicate of bug #2053424 -- Ondro, can you check? There is nothing wrong with the `sk-ecdsa-sha2-nistp256*` keys though ... Jakub, sorry, I'm not sure. When we use OpenSSL implementation, we rely on FIPS certified code. When we use sk-*, we rely on hw provided code that may be (and may be not) certified. Am I correct? Oh, right. I think this will require some clarification before going to final conclusions. There are certainly some FIDO U2F tokens that are FIPS 140-2 certified, either from Yubico or from other vendors. Here is one for Yubikey, which mentions the certified cryptographic module is used for FIDO/U2F: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp3907.pdf The FIDO specifications mention the FIPS 140-2 or -3 in several places so allowing this in FIPS will most likely have some caveats and most likely will require some modifications to the OpenSSH or sk-usbhid.c to satisfy these requirements. https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#sctn-feature-descriptions-alwaysUv-authnr-actions I will be looking into this a bit more in coming months because of the GSoC project for libssh so I can have a better look into this. BZ#2053424 looks a bit different, this one is most likely a bug in the defaults (or in crypto-policies). Looks like a bug in crypto-policies to me. Alex, do you agree? But I don't think we should enable these algorithms in FIPS mode, see https://bugzilla.redhat.com/show_bug.cgi?id=2087915#c2 for justification. Probably a CP FIPS:SK? code pointer: openssh config generator currently does not specify HostKeyAlgorithms in the client configuration with the following justification: # As OpenSSH currently ignores existing known host # entries with this setting we cannot use it on client. # Otherwise we could break existing users. https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/blob/ca01c3e80989f83cc6a0bc61b3a4e997f19ee5ee/python/policygenerators/openssh.py#L196 What is this concern? Is it still a valid concern? Yes, still the case. I think we have some known issue bug for that and upstream bug for that: https://bugzilla.mindrot.org/show_bug.cgi?id=2924 But not merged upstream and not brought downstream as it sounds quite risky. Right now, if we would just define HostKeyAlgorithms in client configuration, the order from c-p would have higher priority than the existing known_hosts files on the client and if the client already has different key in known_hosts than is the first one from c-p, he would get false-positive warnings about hostkey change. We can have FIPS-compliant tokens we may want to deal with, and in these keys it's up to the client. We want to hardcode disabling (sk-)ed25519 in FIPS mode and leave sk-ecdsa as an option *** Bug 2053424 has been marked as a duplicate of this bug. *** Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (openssh bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:8375 |