At present, the bootstrap account/session creation provides credentials which can be used to access all the Redfish Resources/URL's. This is shared with BIOS/UEFI Redfish Client so that it will aid in management of a system via BMC Redfish server. Since these credentials can be used to access any Redfish URL, it can be used by a rogue/malicious UEFI to access the Redfish resources of other systems being managed by the BMC. This leads to security breach as critical data of other systems is now exposed and can be exploited by malicious UEFI. Ideally, each UEFI Redfish Client should be given exclusive access to its designated resources only, without the ability to interfere/access other systems being managed by the BMC.
Are there any standard solutions to avoid the issue ? Thanks !
The only method in place now would be to leverage the "Client certificate authentication" clause in the Redfish spec. The current state of it would likely impact general usage of the system as well, so we might want something more focused client identity certificates installed on the HostInterface resource as a way of enforcing additional verification for these use cases. However, that could lead to provisioning problems where UEFI will need to have a unique certificate with a protected private key, and have the certificate installed on the BMC as well. Beyond using certificates to verify the user, I'm not aware of other possible paths.
In this case, if a malicious actor has access to the KCS interface, it can invoke the "Get Bootstrap Credentials" command to get a set of credentials for the service. The credentials themselves aren't necessarily compromised.
I'm thinking the secure flow would be:
Identity certificates are provisioned for UEFI
The same identity certificates are installed on the BMC
UEFI issues the Get Bootstrap Credentials command to get their username and password
UEFI creates a Redfish session with the BMC with the provided username and password; in addition, UEFI provides its identity certificate during TLS handshaking