Joseph Reynolds wrote: > On 4/6/23 2:00 PM, Michael Richardson wrote: >> Joseph Reynolds 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 . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide