tree 78e3444e0b55df55f512415dbfd34977cdca2350
parent 6c4199afe4dc4d446679b862f528e840e60925df
author Serge Bazanski <serge@nexantic.com> 1612219757 +0100
committer Serge Bazanski <serge@nexantic.com> 1612219757 +0100

metropolis: introduce AAA.Escrow RPC

This is a combined proto change and design document RFC.

This implements a generic 'Escrow' methid, used to allow external
entities to log into a Metropolis cluster. This flow's subject vaguely
corresponds to 'Entity' objects from the Lifecycle DD, but this will be
more precisely defined in a subsequent change which introduces the
actual entities objects, the way they're identified, and the way they're
stored in the cluster.

In addition, this formalizes the part of the LDD in which entities are
able to perform hardware attestation on nodes. The hardware attestation
part is not fully implemented, but is placed within the bounds of the
Escrow streaming RPC. Entities might also be able to performs this
hardware attestation in a separate RPC call (having already requested a
short-lived certificate permitting access to RPC), but this is not yet
sure.

This design, is in a way, a modernized version of GSSAPI. It assumes it
runs over a confidential channel (TLS), and that it only ever returns
x509 certificates emitted for the requesting client. It is also designed
to handle flows that we expect to use within Metropolis.

This design has some known limitations:

1) Limited decisionmaking abitility by the server to decide which proofs
   are needed - ie., the server cannot change its mind what other proofs
   are needed as the client presents some. Currently the server can
   decide the proofs only based on the parameters given by the client,
   and the initial context of the connection, ie. its originating
   address and the presented TLS certificate.
2) Limited expressibility of required proofs to the client, currently
   all listed must be fulfilled.

This, however, can be extended as the protocol evolves, and can continue
to support simple clients that handle only this protocol. Especially 2)
might be limiting us from preventing things like accepting emergency
certificates without necessarily needing an OIDC login, even though OIDC
logins are required for other kinds of certificates. We are explicitly
trying to keep things simple for now, and just not write ourselves into
a corner here.

Finally, this API should cover all scenarios expressed within T865 -
minus the entity storage part within the cluster.

Test Plan: Proto change and review process.

X-Origin-Diff: phab/D698
GitOrigin-RevId: 92892b5522a4d41d572fd4c10f24d26f72919aeb