MTLS support for HTTPS authentication

[Ed Tanous]

I'm investigating the possibility of the web layer in OpenBMC supporting
MTLS for user authentication.  For the uninitiated, mutual TLS is a
mechanism to allow a server to verify whether or not a client can be
"trusted" in a very similar way that the client can verify that the
server is trusted on a standard TLS connection.  This is done during the
setup of the transport, rather than inside the channel once the
transport has been opened.  It also allows users to authenticate without
having any direct credentials (encrypted or not) to hit the wire.  The
hope is that this would allow much easier and more secure use of the
webui, Redfish, and any other https based resource in the BMC.

Overall, the primary goal here is to provide an authentication mechanism
that doesn't require passwords, nor requires the BMC to know any
"secrets" like session tokens, and could authenticate entirely based on
"public" information, thus reducing the possibility for attack.


The flow I'd like to propose is.

1. During provisioning of a system, an administrator uploads the public
certificate for an authority that can be trusted for user
authentication.  This would likely be done through a POST/PATCH to the
new Redfish Certificates schema that was recently released.  At this
point, the administrator/provisioner would have the option of completely
disabling other authentication types (session, basic, ect) to allow ONLY
authenticated types.  For images or deployments that have a known
destination, and known authority, these authorities could be baked into
the image at build time instead of uploaded runtime.  The "phosphor"
reference implementation would default to allowing no authorities until
configured.

2. A user would request a signed certificate (using a CSR) to their
given authority.  This could be as simple as signing a request locally
using openssl, or requesting a cert from a rack level controller
(possibly OpenRMC?).   The exact flows would depend on the authority
being used, and should be considered outside the scope of OpenBMC.  The
CSR would include the CommonName field value of <username>@<bmc
hostname>   (ex ed at EdsBmc).

3. A user would then attach that certificate to their request.  Doing
this in curl would use the --key and --cert parameters.  Most HTTP
clients have similar mechanisms for specifying a client certificate.

4. Upon receiving the connection, the bmc would verify that the
certificate was valid against the certificate authority, then use the
CommonName field to parse out the username, and match it up with a given
BMC user.  That connection would then be authenticated as that that user
until the connection is closed.  The authorization schemes would remain
as they were previously.


Some questions I'd like to pose:

1. Is there something better we can use in the CommonName field to
correctly identify the system name and the user name?  Do we think that
the common authority services people are using will allow signing such a
request?  Is the request detailed enough?
2. How should we handle the date problem?  In a lot of cases, the BMC
might not have access to the current or correct time.  This will cause
validation of the certificate to fail, as in most cases it will have
been signed in the "future" compared to the BMC time.  Should we ignore
the signing dates?  Is there a way to verify we're on NTP time, then
fall back to ignoring the date if NTP is disabled or has failed?  Should
we be strict?  Does this need to be configurable?
3. Should we limit the number of levels of verification we support?
Said another way, should we support anything other than a certificate
chain size of 1?  Should we support configuration of the chain length?
Is there some upper bound we should impose?
4. Is anyone else interested in pursuing?


-Ed