Design to isolate BMC service access

[Joseph Reynolds]

On 4/6/23 2:00 PM, Michael Richardson wrote:
> Joseph Reynolds <jrey at linux.ibm.com> wrote:
>      > A "service access token" is proposed.  Details are below but for now, a
>      > service access token:
>
>      >  * Is a small file (kilobytes), a digitally-signed request to access a
>      > specific BMC function on a specific BMC for a limited time window.
>      > This token may have additional information about its origin, etc.  * Is
>      > created by an authorized service agent.  Only service agents can
>      > digitally sign the tokens so they can be verified by the BMC.  * Is
>      > uploaded to the BMC by an admin user to perform a specific service
>      > function.  * Has nothing that is secret to the BMC admin user.  If the
>      > token encodes a password, it is stored in the form of a secure hash.
>
> So it's a bearer token (?) that is encrypted by the BMC to itself?
> Or it's created by an external entity?

Michael,  +cc: Ed Tanous
Thanks for your input!

This token is digitally signed by the service organization behind their 
firewall.  When it is uploaded to the BMC the signature is verified by 
the BMC.  I didn't describe the infrastructure needed for this, but it 
includes the following pieces:
1. The BMC functions described in this design sketch.
2. The service organization creates a key pair for the service access token:
2A. The private key is held by the service organization to digitally 
sign the token.
2B. The public keys gets built into the BMC firmware image to validate 
the token's signature.

The "steps" in the next paragraph of the original design sketch are 
intended to show when the token is signed and validated...
In step 2, the service agent creates the token and uses their privileged 
access (behind their organization's firewall) to the private key to sign 
the token.
In step 3, the BMC admin gets a copy of this signed token and uploads it 
to the BMC.
In step 4, the BMC validates the token's signature.

Note that step 1 describes the BMC optionally generating a "service 
request token" which might be signed by the BMC and validated by the 
service organization (the flow is the opposite direction from the 
"service access token").


> Very much exactly OAUTH2-like: JWT, CWT. In fact... I suggest not
> re-inventing the wheel here.

Thanks for that!  I think that would work.  The service organization 
would build an OAuth2 JSON Web Token (JWT) which is uploaded to the 
BMC.  I will study up and try to redo this design sketch in those terms.


>
> Do you intend to sometimes bind the token to the specific user (service team,
> I think).

Yes, the basic premise is: the token is (a) created by the service agent 
(person) to (b) do something specific on the BMC while using the BMC's 
service account.


>
>      > call.  The admin passes this data to the service agent along with their
>      > request for service.
>
> There are now some IETF protocols (TIGRESS WG) that enable this secure transfer.
>
>      > indicated within the service access token.  Design question: Should the
>      > function be activated when it is uploaded, or via a separate activate
>      > function?
>
> When it is uploaded.
> If you want it to take effect in the future, then the token should have a
> notBefore entry.
>
>      > 5. If the service function is to allow root login to the BMC
>      > command shell, the service user can now login to the BMC, using a
>      > unique password associated with the service access token, and known
>      > only them.
>
> No passwords.
> If you are going to use SSH, then use SSH keys here.

I agree that makes sense for SSH users, but our service organization has 
situations where they are not allowed to take any electronic materials 
into the customer site (and the customer will not carry it either), so 
our service techs sometimes still need an option for password access.  
Perhaps password access should not be the default option.


>
>      > 6. Other popular functions might be to recover the admin
>      > account, disable various security features, or perform a service dump.
>      > Example: Customers regularly call for service because they lost access
>      > to their admin account.  Recovery means, for example: recreate the
>      > admin account or set it to a usable state, and set its password to a
>      > known value, reset its password lockout, etc.
>
> That seems like a chicken and egg situation, but maybe I don't understand it.

You got it, "How can an admin give permission to a service agent to 
recover the admin account of their BMC, if the admin is locked out?" 
-->  One way to accomplish this is to have assert "physical presence" 
(such as invoking function 74 on the operator panel -- which can only be 
done by someone physically present at the system), and when this is done 
the BMC will omit the admin authorization required to upload the service 
token (but perform all other checks).  (Then the system owner has to 
keep authorized service agents away from their systems!)  I do not 
intend to try to standardize this approach.
Is there a better way to solve this problem?


>
>      > 1. Is this design sketch clear?  What improvements are needed?
>
> Relatively.
>
>      > 4. Should the "service access
>      > token" be an X.509 certificate?  Or is that inappropriate?
>
> No.  It's just gonna confuse people.
>
>      > should that be a separate step?  For example, a BMC admin might want
>      > to: (A) upload a token, (B) inspect the token (using the BMC function)
>      > to ensure it looks legitimate and perform the function they agreed to,
>      > and then finally (C) activate the token, for example, to disable secure
>      > boot.
>
> Maybe that's a reasonable work flow.
>
>      > 8. Does it make sense to have a common implementation for the
>      > functions as listed above (like to recover admin account access).
>
> I don't know.
>
>