|
|
Post by pparth on Sept 28, 2020 16:07:05 GMT
I'm new to OpenBMC and Redfish! From a security perspective I'd like to be able to enforce mTLS-only authentication when using OpenBMC's BMCWeb that implements Redfish. mTLS-only would mean: disabling and disallowing all other auth methods (including basic auth) and disabling unauthenticated access to static content [1]. i.e. no end point could be reached without successfully completing an mTLS connection setup first. From what I've been told: enforcing mTLS-only would violate the Redfish standard (either currently or in the future). Is that correct? Can someone understand which parts and why/how? Assuming this is true, I'd like to understand what would need to be done to make mTLS-only an acceptable state from (a future) Redfish standard's perspective as I think there's a good and strong security case that can be made for some enterprises to prefer this mTLS exclusively. [1] github.com/openbmc/bmcweb/blob/cb13a39253848ece442971301ade9c09d98bf08e/include/authorization.hpp#L204-L235 |
|
|
|
Post by josephreynolds1 on Sept 28, 2020 18:05:02 GMT
Details: - This is related to (but different from) redfishforum.com/thread/362/support-mtls-oauth. - I understand the Redfish standard requires services (like BMCeb's Redfish service) to support Basic Auth per Redfish DSP0266 > Security details > Authentication. Exact reference: www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.11.1.pdf section 14.3 "Authentication", page 150, first sentence reads, "[Services] Shall support both HTTP Basic authentication and Redfish session login authentication." - As far as I can tell, endpoint URIs such as /redfish, /redfish/v1, /redfish/v1/$metadata, and /redfish/v1/odata must not require authentication. See section 8.2.2 "Service root request". Also, the OpenBMC BMCWeb server allows unauthenticated users to POST to /redfish/v1/SessionService/Sessions to create a new session. Do you want to disallow that? |
|
|
|
Post by pparth on Sept 28, 2020 19:32:43 GMT
Thanks Joseph.
>> As far as I can tell, endpoint URIs such as /redfish, /redfish/v1, /redfish/v1/$metadata, and /redfish/v1/odata must not require authentication. See section 8.2.2 "Service root request". Also, the OpenBMC BMCWeb server allows unauthenticated users to POST to /redfish/v1/SessionService/Sessions to create a new session. Do you want to disallow that?
To answer your question: yes if mTLS-only is enabled. The intent is to close all other doors for an attacker to try and exploit. I'd like to reduce the attack surface to this single authentication mechanism. So in the mTLS-only case, the only way for an attacker would be to break mTLS or find a vulnerability in the code handling mTLS.
As an example, for 8.2.2 we can change the sentence something like: "Services shall not require authentication to retrieve the Service Root and /redfish resources unless mTLS-only mode is enabled." A section on the security benefits of mTLS-only can be added somewhere in the specification as well if necessary that lays out the implications on other protocols & authentication mechanisms.
mTLS-only authentication actually happens at the transport layer (in BMCWeb implemented by boost) so the services don't have to do any active work. This is an intentional security win as the attack surface for those services does not require extensive security review.
From a security perspective, having the option to limit your security exposure seems like a big win. What would be necessary to make Redfish standard reflect this? Surely there are other customers who would also find this idea persuasive and worthwhile?
|
|
|
|
Post by josephreynolds1 on Sept 30, 2020 15:30:08 GMT
I understand this is a request to change the spec to allow a new "mTLS only" use case. My guess for this use case is: - The BMC is pre-provisioned with an admin account, no password authentication, and a mTLS certificate. - The BMC's Redfish client is pre-provisioned with the mTLS certificate paired with the one on the BMC. - The BMC's Redfish client uses a mTLS-capable client such as pypi.org/project/mtls/. - With the above items, the BMC can be installed out-of-box and powered on, then the client can discover it in the usual way and then immediately use mTLS authentication. Is that right? Redfish seems to partially support this with SessionService ServiceEnabled property together with an Oem property to allow mTLS authentication. For example, the service would set ServiceEnabled=false and an Oem property. OpenBMC seems to implement this as /redfish/v1/AccountService Oem.OpenBMC.AuthMethods includes "TLS" as implemented in github.com/openbmc/bmcweb/blob/master/redfish-core/lib/account_service.hpp |
|
|
|
Post by jautor on Sept 30, 2020 15:58:15 GMT
Assuming that is the use case, with mTLS used as an OEM-specific authentication mechanism, we should do some enhancement to the AccountService to allow customers to individually enable/disable the standard and OEM mechanisms - and need to ensure in the normative language that you cannot "disable all" to prevent total lock-out. The existing "ServiceEnabled" property does this for Session-based authentication (which is why it mentions that Basic Auth is not affected) - we should provide the ability to do the opposite (and also allow both to be disabled when an OEM authentication method is present and enabled).
pparth - note that unless the use of mTLS is completely transparent to client code, operating a system in this "mTLS only" mode would likely prevent Redfish clients from working. If the intent is truly a purpose-built setup where both client and service software is all known to work, that's fine - but just wouldn't want to have you start down a path that isn't practical if that isn't the use case.
Jeff
|
|
