De-couple KBS session management from attestation service

[tylerfanelli]

Each client attesting with the KBS has a session that tracks the "attestation state" of that client (authenticated or attested). Currently, the sessions are managed by the AttestationService struct (found here), which means they are hidden behind the as feature.

IMO, the managing of sessions largely has nothing to do with the underlying attestation service. I'm wondering if others agree and feel they should be managed by the ApiServer directly.

[fitzthum]

I think the sessions are only used to store the state of the RCAR handshake. Once that is completed, Trustee gets the TEE public key from the token. We would have the as feature disabled for something like a passport mode KBS, which expects the guest to have already obtained a token from somewhere else.

My first impression is that using the AS feature here is fine, but is this causing a problem?

[fitzthum]

btw one related thing is that we've talked about moving this sessions map out of memory to support high-availability deployments.

[tylerfanelli]

I think the sessions are only used to store the state of the RCAR handshake. Once that is completed, Trustee gets the TEE public key from the token. We would have the as feature disabled for something like a passport mode KBS, which expects the guest to have already obtained a token from somewhere else.

It's mainly stemming from two-way encryption (not added yet, but a potential implementation in #728). Each session generates a RSA key that is used for two-way encryption with the client. Each time a request enables two-way encryption the KBS needs to use the session to find the correct decryption key. We can't put that in the token, so we must use the session ID.

My first impression is that using the AS feature here is fine, but is this causing a problem?

Nothing wrong at the moment, but I'm wondering if this change would help "future-proof" the KBS. I think I mistook the as feature for meaning the trustee attestation-service, rather than ANY attestation service.

For instance, if at some point Veraison were to be plugged in to the attestation service's role, the as feature would likely still need to be enabled. But that begs the question in what kind of deployment would the KBS be running while the as feature is disabled? If attestation services were delegated to another party?

[fitzthum]

It's mainly stemming from two-way encryption

We probably don't want to tie this to sessions if possible. I will try to go through your PR in the next day or two.

For instance, if at some point Veraison were to be plugged in to the attestation service's role, the as feature would likely still need to be enabled. But that begs the question in what kind of deployment would the KBS be running while the as feature is disabled? If attestation services were delegated to another party?

Yes, when we use other attestation services we still want to keep track of the rcar handshake data (mainly the nonce) in the KBS. The case where we don't need the handshake info is when we are using the passport mode. Our passport mode is slightly different from what RATS defines btw. In our case we have two KBSes one is attached to an AS but doesn't have any resource backends or plugins. The guest does the handshake with this KBS and gets a token. The second KBS has no AS but it has resources. The guest shows up at the second KBS with the token and gets a resource. The passport mode isn't super widely used but we gotta support it and ideally the two-way encryption would work in this mode as well.

Btw we do have veraison support but it's kind of buried in the ARM CCA verifier. Now that we support EAR tokens natively we could probably do this much more elegantly.

[tylerfanelli]

It's mainly stemming from two-way encryption

We probably don't want to tie this to sessions if possible.

Totally agree. Two different issues completely, I don't intend to solve it there.

I will try to go through your PR in the next day or two.

Thanks, no rush.

For instance, if at some point Veraison were to be plugged in to the attestation service's role, the as feature would likely still need to be enabled. But that begs the question in what kind of deployment would the KBS be running while the as feature is disabled? If attestation services were delegated to another party?

Yes, when we use other attestation services we still want to keep track of the rcar handshake data (mainly the nonce) in the KBS.
The case where we don't need the handshake info is when we are using the passport mode. Our passport mode is slightly different from what RATS defines btw. In our case we have two KBSes one is attached to an AS but doesn't have any resource backends or plugins. The guest does the handshake with this KBS and gets a token. The second KBS has no AS but it has resources. The guest shows up at the second KBS with the token and gets a resource. The passport mode isn't super widely used but we gotta support it and ideally the two-way encryption would work in this mode as well.

Thanks for the context.

Btw we do have veraison support but it's kind of buried in the ARM CCA verifier. Now that we support EAR tokens natively we could probably do this much more elegantly.

Adding better support for it is on my radar.

[Xynnn007]

It's mainly stemming from two-way encryption (not added yet, but a potential implementation in #728). Each session generates a RSA key that is used for two-way encryption with the client. Each time a request enables two-way encryption the KBS needs to use the session to find the correct decryption key. We can't put that in the token, so we must use the session ID.

For this piece, I would like to have a more general design that covers two-way data encryption, specifically utilizing HTTPS.