Re: Design to isolate BMC service access

[Michael Richardson <mcr+ietf@sandelman.ca>]

[-- Attachment #1: Type: text/plain, Size: 4099 bytes --]


Joseph Reynolds <jrey@linux.ibm.com> wrote:
    > On 4/6/23 2:00 PM, Michael Richardson wrote:
    >> 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?

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

2B seems like a kicker to me.
I have been working on (too slowly, without enough resources), an RFC8995
client (pledge) for OpenBMC, which would allow for that token validation
public key/trust-anchor to be delivered to the BMC at boot time/installation.

RFC7030 (EST) seems like a very good way to do this, and even without RFC8995
to automate it, entering a URL into the BMC web interface and having it
transfer the trust-anchor seems like a good thing.  That also gets it access
to CRLs and to refreshing the trust-anchor.

I think that there should also be a self-signed option where the BMC creates
the token itself.  In that case, having it be a bearer token has pluses and
minuses.  linking it to a TLS Client certificate would be good in some use
cases.

I think that there are two deployment environments:
1) the facebook/etc. scale places where they just need automation and can pay
   for it.
   
2) the SMEs where they have a few dozen systems, installed by a variety of
   people with a variety of skills, probably at least one of them have left.
   They are chronically under-resourced, and being able to recover easily is
   important.

(The really SMALL places with four systems can probably just poke a button to reset
the BMC to factory defaults.  I had to do that to a 2010 era server on
Wednesday after the ice storm killed power, and the UPS went with it... Gosh
I wish that system was running something modern)

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

Yes.  That way, you can leverage not just the crypto primitives, but also the
operational experience around that.

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

Good.


-- 
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide





[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]