Joseph Reynolds <jrey@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?

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

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

    > 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.

    > 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.

    > 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.