Support push model for agent attestation

[THS-on]

Enhancement Description

• One-line enhancement description (can be used as a release note): Instead of polling the agent for attestation data the agent sends the data periodically to one or more verifiers
• Keylime Enhancement Proposal: follows after initial discussion of the draft
• Recommended skills: Python, understanding of authentication with client side TLS
• Primary contact (assignee): Thore Sommer @THS-on
• Enhancement target (which target equals to which milestone):
  • Alpha release target (x.y)
  • Beta release target (x.y)
  • Stable release target (x.y)

Initial draft and longer description of the change can be found here: https://gist.github.com/THS-on/aedfd139ac1cb012745abeb0276d5e5c

[khansaAmrouni]

Hi,
my name is khansa, as a GSOC candidate, this project interests me!
my question is:
what should I do as a get started step.
thank you.

kind regards,

[THS-on]

Hi @khansaAmrouni,
the first thing that you'll need to do is get Keylime running either in a VM or on bare metal. Keylime is packaged for Fedora and OpenSUSE or you can use the installer.sh script in the main Keylime repo. Once you have a test setup running familiarize yourself with the different components (agent, tenant, registrar and verifier). For questions and general information join #keylime channel on the CNCF Slack.

An initial draft of the enhancement is linked in this issue. Try to understand what is described in there and ask questions if something is not clear. Once you think have a general understanding and we discussed the idea, you can start writing a proposal for this change. Note that if multiple people want to work on this, we might have competing proposals.

We currently have no specific template for a GSOC proposals, but you can look at the enhancements in this repository in combination with the guide from GSOC (https://google.github.io/gsocguides/student/writing-a-proposal#elements-of-a-quality-proposal). Also this post is a good read: https://sayak.dev/gsoc-faqs/

For understanding TPMs in general I suggest having a look this book: https://link.springer.com/book/10.1007/978-1-4302-6584-9

If you want to better get to know the code base and workflows of Keylime by improving the code, I suggest to have a look at keylime/keylime#929.

A general overview of Keylime can be found in the documentation: https://keylime-docs.readthedocs.io/en/latest/design.html

[mpeters]

btw @THS-on this is a great response in general for other GSOC applicants. Let's save it and modify as needed

[khansaAmrouni]

Hi,

nice! thank you.

[hmuhammadazeem]

Hi, is there a chat or other communication channel for the GSoC 2022 project relating to this issue?

[THS-on]

@hmuhammadazeem there is no extra chat for GSoC, but you can either comment on this issue or join #keylime on the CNCF Slack (https://slack.cncf.io/).

[stefanberger]

I am currently not fully aware of the all the details of the protocol going on between all the components during agent registration by keylime_tenant. There is for example the file passed via -f flag, and the 'K', 'V' and 'U' parameters, and what the necessity behind them is. Though here is a shot as some initial discussion points for the push model:

Gates for the agent to communicate with verifier:

• not just any want-to-be agent can talk to the verifer but an agent must hold a client side SSL certificate issued by known CA for agent to be allowed to talk to verifier
  • the certificate should probably contain the UUID of the agent in the subject line somewhere (CN=); this prevents multiple re-use of the same certificate by just any agent
  • however, we also need to prevent a certificate (for a UUID) to be used by multiple agents claiming to be using the same UUID concurrently
• As a 2nd gate, the UUID of the agent must be registered for the agent to be allowed to run the 'push-model protocol' with the verifier

Push-model Protocol

• The keylime_agent is to be used with '-c add' and '--push' flag to register an agent using the push model
  • the push-model flag cannot be changed anymore unless of course one does a '-c delete' to de-register an agent
  • once registered, the agent is allowed to talk to the verifier
  • some IP address options of the tenant tool are unnecessary for the push model
• The agent can try to talk to verifier while it is not registered but it will be rejected to submit quotes etc. based on UUID in client certificate
• Initially an agent queries the verifier for report-interval, which could be like 10 seconds, within which an agent must send a quote to the verifier to not go into INVALID (?) state
• As a consequence of this, the verifier must process timeouts for agents that did not report within report-interval and raise alarms
• Further, a graceful shutdown of an agent requires notification to the verifier to avoid an alarm being raised
• The agent may need to run some sort of bootstrapping steps that typically the tenant was running upon '-c add'; whether it needs to bootstrap or has been bootstrapped already could be found out by the agent when querying for the report-interval
• Once the agent has been registered it can start sending quotes with logs as usual
  • the verifier needs an API for this that requires similar / or the same parameters that the verifier received back from the agent in the pull model
• An agent that is in invalid state (due to failure to report or attestation failure) will need to be handled again by the keylime_tenant as in the push model, e.g. '-c update'
• An agent that has been deleted from the verifier/registrar using '-c delete' must be registered again

=> The current multi-processing registrar would additionally have to become a multi-processing (threading?) tornado server. The 'AgentAttestState' would have to be loaded from and stored into a DB table upon every attestation step along with the 'agent'.

[been editing this item quite a bit...]

[stringlytyped]

Since it has been a while since there has been discussion on this issue, I am taking the opportunity to update it with some recent developments. In last week's community meeting, there was considerable discussion around the topic of push support. Thanks to everyone who participated in that!

To briefly summarise the outcome of that discussion:

• It was decided that the push protocols would not need to support the payload feature. This allows enterprise users of Keylime to simply opt into a more secure operating model without negatively impacting existing users who rely on payloads today.
• Settled on adding a request to the attestation protocol for obtaining the nonce, PCR mask, IMA offset, etc. (which is what @THS-on has proposed above). Possibilities for optimising this can be explored down the line.
• The idea to move checking of the EK and NK into the registrar (again, first proposed above) was well received.
• It can be assumed that each agent will only need to attest to a single verifier (scaling in the push model can be achieved by placing multiple verifiers behind a load balancer).
• Each verifier will operate in either push or pull mode and won't need to support both push and pull agents side by side.

I've expanded on these points and further drilled into the protocol and architecture-level changes which are needed for implementation of the push feature in a report I'm making available for consideration by the community: Roadmap to Push Model Support in Keylime

Please let me know if anyone has any feedback regarding the changes outlined in that document. Look forward to hearing your thoughts!

[THS-on]

Superseded by #103