Re: Security Working Group meeting - Wednesday August 31 - results

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

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


Joseph Reynolds <jrey@linux.ibm.com> wrote:
    > In my limited comprehension, the end-to-end flow is:
    > 1. The BMC boots up and extends measurements into its TPM.
    
    > 2. the BMC admin configures the BMC's Keylime Agent.  That is, starts the
    > "Keylime Agent service", and provisions certificates, etc.

Number 2 has to occur, but only once, while you have put it into a regular flow.

    > 3. A network agent (a "Keylime Verifier") contacts the BMC's Keylime Agent
    > and asks for the measurements.  The Agent that queries the TPM and provides
    > the measurements.

Yes, but maybe not for anyone that asks.
The measurement (Evidence) needs to be signed by the TPM (that's part of the protocol).
There is a freshness requirement, for instance the Verifier can provide a
nonce through the protocol to be included in the signed Evidence.  Another
way is to use a TLS Extractor (TLS-Unique in TLS <1.3) to get a key.

You can read more about the architecture at:
    https://www.ietf.org/archive/id/draft-ietf-rats-architecture-21.html#name-architectural-overview
(Yes, I'm a lead author)
I've been really busy on Wednesdays, so I haven't joined lately, but I could
if you want to talk more about this stuff.

    > Redfish has specs for getting server TPM measurements, but does not have any
    > specs for getting BMC TPM measurements.
    > Because of this, the group doing the work is proposing for the BMC's Keylime
    > Agent service to open a separate port, and to not use Redfish to get the
    > actual measurements.  In support of this view: there are Keylime verifiers
    > already available to use this new port, but there are no Keylime verifiers to
    > use Redfish.

Sounds accurate, but it seems like doing it through redfish is entirely
reasonable to me.

    > It should be clear from the paragraphs above that the intended use case is
    > for a client server model, not a network of peers.  The Keylime Verifier
    > client running on the BMC's management network contacts the Keylime Agent
    > running on the BMC.  The mutual-TLS method is used for authentication.

    > Keylime is written in Python.  I think the the idea was to either port that
    > version, or to use the new implementation in Rust.  We did not discuss any
    > difficulties in image size increase due to Python or in getting the Rust
    > language environment ported to bitbake.

I imagine that the bitbake recipe is probably the critical path, but I also
suspect that Rust is being used somewhere with bitbake.



-- 
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-




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