Security Working Group meeting - Wednesday August 31

Security Working Group meeting - Wednesday August 31

[Joseph Reynolds]

This is a reminder of the OpenBMC Security Working Group meeting 
scheduled for this Wednesday August 31 at 10:00am PDT.


ATTNTION - Venue Change.  The meeting moved to Discord voice, beginning 
with this meeting.  Please update your calendars.

=== MEETING ACCESS ON DISCORD VOICE starting on Aug 31, 2022  ===

Discord > OpenBMC > Voice channels >  Security ~ 
https://discord.com/channels/775381525260664832/1002376534377635860 
<https://discord.com/channels/775381525260664832/1002376534377635860>



We'll discuss the following items on the agenda 
<https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI>, 
and anything else that comes up:

1. Continue Measured Boot discussion.

2. Gerrit review: Proposal for dynamic changes to Redfish authorization 
rules https://gerrit.openbmc.org/c/openbmc/docs/+/56401


Access, agenda and notes are in the wiki:
https://github.com/openbmc/openbmc/wiki/Security-working-group 
<https://github.com/openbmc/openbmc/wiki/Security-working-group>

- Joseph

Re: Security Working Group meeting - Wednesday August 31 - new venue

[Joseph Reynolds]

Effective immediately, the Security Working Group meeting access is on 
Discord voice.  Please update your calendars.   The meeting date and 
time is unchanged.

Discord > OpenBMC > Voice channels >  Security:
https://discord.com/channels/775381525260664832/1002376534377635860


On 8/30/22 8:08 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday August 31 at 10:00am PDT.
>
>
> ATTNTION - Venue Change.  The meeting moved to Discord voice, 
> beginning with this meeting.  Please update your calendars.
>
> === MEETING ACCESS ON DISCORD VOICE starting on Aug 31, 2022  ===
>
> Discord > OpenBMC > Voice channels >  Security ~ 
> https://discord.com/channels/775381525260664832/1002376534377635860 
> <https://discord.com/channels/775381525260664832/1002376534377635860>
>
>
>
> We'll discuss the following items on the agenda 
> <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI>, 
> and anything else that comes up:
>
> 1. Continue Measured Boot discussion.
>
> 2. Gerrit review: Proposal for dynamic changes to Redfish 
> authorization rules https://gerrit.openbmc.org/c/openbmc/docs/+/56401
>
>
> Access, agenda and notes are in the wiki:
> https://github.com/openbmc/openbmc/wiki/Security-working-group 
> <https://github.com/openbmc/openbmc/wiki/Security-working-group>
>
> - Joseph

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

[Joseph Reynolds]

On 8/30/22 8:08 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday August 31 at 10:00am PDT.
>
>
> ATTNTION - Venue Change.  The meeting moved to Discord voice, 
> beginning with this meeting.  Please update your calendars.
>
> === MEETING ACCESS ON DISCORD VOICE starting on Aug 31, 2022  ===
>
> Discord > OpenBMC > Voice channels >  Security ~ 
> https://discord.com/channels/775381525260664832/1002376534377635860 
> <https://discord.com/channels/775381525260664832/1002376534377635860>
>
>
>
> We'll discuss the following items on the agenda 
> <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI>, 
> and anything else that comes up:

Attendees (as Discord screen names): josephreynolds, galmasi, alda, 
ddaniil, dsp, fnichols3, jiangz, pgc, Rob, RussWilson, 
skotheshwara,YutakaSugawara.


0 We took about 15 minutes to try out the new Discord voice access and 
to escort folks from the old Webex meeting.

1 Continue Measured Boot discussion

DISCUSSION: Create two separate designs for:

  *

    Enable measured boot.

  *

    Enable Keylime Agent.  Direction is for the keylime agent to open
    the BMC network port (using systemd, sort of like how SSH works). 
    The intention is to engage with Redfish for how to configure the
    Keylime Agent: certificates, start/stop the application, etc.


2  Proposal for dynamic changes to Redfish authorization rules 
https://gerrit.openbmc.org/c/openbmc/docs/+/56401 
<https://gerrit.openbmc.org/c/openbmc/docs/+/56401>

No discussion.


3 Proposal to change the meeting time so folks from other time zones can 
better participate.

We are also looking for alternate (non voice) ways to cover the material.

We looked at recording the call, but Discord does not have a record button.

We proposed alternating meeting times to cover time zones in California, 
US Central, Europe, India, China, and Australia.  (So, pretty much the 
whole world.)

TODO: Joseph to create a poll, suggest alternate meeting times: 9am CDT 
& 5pm CDT or 8am Australia.



>
> Access, agenda and notes are in the wiki:
> https://github.com/openbmc/openbmc/wiki/Security-working-group 
> <https://github.com/openbmc/openbmc/wiki/Security-working-group>
>
> - Joseph

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

[Patrick Williams]

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

On Wed, Aug 31, 2022 at 01:09:10PM -0500, Joseph Reynolds wrote:

> DISCUSSION: Create two separate designs for:
>     Enable Keylime Agent.  Direction is for the keylime agent to open
>     the BMC network port (using systemd, sort of like how SSH works). 
>     The intention is to engage with Redfish for how to configure the
>     Keylime Agent: certificates, start/stop the application, etc.

I guess you said someone is working on a design for this.  The Keylime
website seems light on details to me, but I'm having trouble
conceptualizing how it is applicable to the BMC.  It seems more like it
is geared towards a self-selecting cluster of services (which reject
peers they don't trust).  Keylime does have the unfortunate aspect of being
written entirely in Python, which makes it very difficult for us to support
on any of the NOR-based systems (all of them except IBM's latest).

Are we also planning on providing attestation information over Redfish?

-- 
Patrick Williams

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

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

[Patrick Williams]

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

On Wed, Aug 31, 2022 at 01:09:10PM -0500, Joseph Reynolds wrote:

> 2  Proposal for dynamic changes to Redfish authorization rules 
> https://gerrit.openbmc.org/c/openbmc/docs/+/56401 
> <https://gerrit.openbmc.org/c/openbmc/docs/+/56401>
> 
> No discussion.

Does "no discussion" mean?
   - This topic was not covered.
   - Nobody present seemed to have an opinion.
   - Everyone present was onboard with it as-is.

I'm trying to gauge where consensus is at.

-- 
Patrick Williams

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

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

[Brad Bishop]

On Thu, Sep 01, 2022 at 06:25:24AM -0500, Patrick Williams wrote:

>written entirely in Python, which makes it very difficult for us to support
>on any of the NOR-based systems (all of them except IBM's latest).

Is the suggestion that they rewrite it in C++ and contribute that?  If 
it is, why would they invest in building a project and community from 
scratch as opposed to using an existing one just because all the other 
in-tree servers are hyper-cost optimized?

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

[Patrick Williams]

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

On Thu, Sep 01, 2022 at 08:41:53AM -0400, Brad Bishop wrote:
> On Thu, Sep 01, 2022 at 06:25:24AM -0500, Patrick Williams wrote:
> 
> >written entirely in Python, which makes it very difficult for us to support
> >on any of the NOR-based systems (all of them except IBM's latest).
> 
> Is the suggestion that they rewrite it in C++ and contribute that?  If 
> it is, why would they invest in building a project and community from 
> scratch as opposed to using an existing one just because all the other 
> in-tree servers are hyper-cost optimized?

I'm not suggesting anything at this point.  I don't really understand
what Keylime achieves.  I'm just pointing out that it is Python which is
another negative for it.

-- 
Patrick Williams

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

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

[Michael Richardson]

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


My understanding is that keylime is being rewritten in Rust.
(but, it was a comment made in possing, which maybe I misunderstood)

{Also IETF RATS Architecture editor...}

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

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

[Thore Sommer]

> My understanding is that keylime is being rewritten in Rust.

The Keylime agent is rewritten in Rust and the plan is that it will
become the official agent over the next couple of months.
The tracking issue can be found here:
https://github.com/keylime/keylime/issues/986

The server components are in Python and there is currently no plan to
change that.

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

[Joseph Reynolds]

On 9/1/22 6:25 AM, Patrick Williams wrote:
> On Wed, Aug 31, 2022 at 01:09:10PM -0500, Joseph Reynolds wrote:
>
>> DISCUSSION: Create two separate designs for:
>>      Enable Keylime Agent.  Direction is for the keylime agent to open
>>      the BMC network port (using systemd, sort of like how SSH works).
>>      The intention is to engage with Redfish for how to configure the
>>      Keylime Agent: certificates, start/stop the application, etc.
> I guess you said someone is working on a design for this.  The Keylime
> website seems light on details to me, but I'm having trouble
> conceptualizing how it is applicable to the BMC.  It seems more like it
> is geared towards a self-selecting cluster of services (which reject
> peers they don't trust).  Keylime does have the unfortunate aspect of being
> written entirely in Python, which makes it very difficult for us to support
> on any of the NOR-based systems (all of them except IBM's latest).

Yes, an IBM group is working this design.  The design we discussed in 
the security working group meeting has two parts, which I barely 
comprehend.  The parts are:
1. Code running on the BMC will "extend measurements" to a trusted 
platform module (TPM).  Two separate pieces of code are in U-Boot and in 
the Kernel.  The "measurements" are the readonly code image being loaded 
and run.
2. Code running on the BMC (the Keylime "Agent") will query the TPM and 
offer the results to whoever asks.

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.
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.

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.

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.

Joseph

> Are we also planning on providing attestation information over Redfish?
>

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

[Joseph Reynolds]

On 9/1/22 6:27 AM, Patrick Williams wrote:
> On Wed, Aug 31, 2022 at 01:09:10PM -0500, Joseph Reynolds wrote:
>
>> 2  Proposal for dynamic changes to Redfish authorization rules
>> https://gerrit.openbmc.org/c/openbmc/docs/+/56401
>> <https://gerrit.openbmc.org/c/openbmc/docs/+/56401>
>>
>> No discussion.
> Does "no discussion" mean?
>     - This topic was not covered.
>     - Nobody present seemed to have an opinion.
>     - Everyone present was onboard with it as-is.
>
> I'm trying to gauge where consensus is at.

I use "no discussion" when the topic was introduces and described, but 
nobody expressed any interest or asked any questions.  I think someone 
asked for the review link, which was already in the agenda. <-- Is there 
a better way I could say this in the meeting minutes?
When an agenda item is skipped or omitted from the meeting, I'll put 
something like "the following topics were not covered" with the reason why.

Joseph

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

[Joseph Reynolds]

On 9/1/22 7:41 AM, Brad Bishop wrote:
> On Thu, Sep 01, 2022 at 06:25:24AM -0500, Patrick Williams wrote:
>
>> written entirely in Python, which makes it very difficult for us to 
>> support
>> on any of the NOR-based systems (all of them except IBM's latest).
>
> Is the suggestion that they rewrite it in C++ and contribute that?  If 
> it is, why would they invest in building a project and community from 
> scratch as opposed to using an existing one just because all the other 
> in-tree servers are hyper-cost optimized?

I read "applicability" into Patrick's question.  My first thought was 
someone asking why IBM is proposing to put complex and space-consuming 
features into the project, and who else needs them?

I recall from the meeting, but didn't put into the minutes, that the 
Keylime project is creating an implementation based on the Rust language.
The OpenBMC project discussed Rust some years ago, as a language which 
adds additional safety guarantees.  But I am aware of no discussion or 
progress since then, and I didn't find any Rust support in the 
OpenEmbedded/bitbake project (but I think it would be welcome).

Joseph

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

[Michael Richardson]

[-- 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 --]

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

[Patrick Williams]

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

Overall, I don't have strong opinions if someone wants to implement the
Keylime agent as an option for attestation if they think their customers
will find value in it.  I do think we should be careful about any
wording that suggests it is the preferred way because at this time I'm
not convinced it is an appropriate solution for the majority of users.

I'm not expecting IBM to implement attestation over Redfish but I
suspect that will be far more applicable in a general sense.

I could be wrong on Keylime.  My initial reaction is that it is going to
be difficult to get a broad install base on the Verifier side.

On Mon, Sep 05, 2022 at 01:56:39PM -0500, Joseph Reynolds wrote:
> On 9/1/22 6:25 AM, Patrick Williams wrote:
> > On Wed, Aug 31, 2022 at 01:09:10PM -0500, Joseph Reynolds wrote:
> >
> >> DISCUSSION: Create two separate designs for:
> >>      Enable Keylime Agent.  Direction is for the keylime agent to open
> >>      the BMC network port (using systemd, sort of like how SSH works).
> >>      The intention is to engage with Redfish for how to configure the
> >>      Keylime Agent: certificates, start/stop the application, etc.
> > I guess you said someone is working on a design for this.  The Keylime
> > website seems light on details to me, but I'm having trouble
> > conceptualizing how it is applicable to the BMC.  It seems more like it
> > is geared towards a self-selecting cluster of services (which reject
> > peers they don't trust).  Keylime does have the unfortunate aspect of being
> > written entirely in Python, which makes it very difficult for us to support
> > on any of the NOR-based systems (all of them except IBM's latest).
> 
> Yes, an IBM group is working this design.  The design we discussed in 
> the security working group meeting has two parts, which I barely 
> comprehend.  The parts are:
> 1. Code running on the BMC will "extend measurements" to a trusted 
> platform module (TPM).  Two separate pieces of code are in U-Boot and in 
> the Kernel.  The "measurements" are the readonly code image being loaded 
> and run.
> 2. Code running on the BMC (the Keylime "Agent") will query the TPM and 
> offer the results to whoever asks.

This is very concerning to me.  There is no authentication?

Blindly advertising to the world which versions of firmware you are
running so an attacker knows exactly which vulnerabilities you are
likely to have doesn't sound appealing.

> 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.
> 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.
> 
> 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.  

The way this is worded feels a bit like a stretch argument.  If Redfish
already has a schema for getting the measurements for a managed entity,
wouldn't it be trivial to extend this schema for the management entity?

> 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.
> 
> 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.

Alright.  Maybe there is authentication?

mTLS presents a bit of a chicken-and-egg issue, doesn't it?

    1. I don't want to install device-level certificates on a device I
       haven't attested.

    2. I can't attest a device until I install device-level
       certificates on it in order to support mTLS.

You've briefly mentioned "BMC admin" above, which sounds like something
manual a human does.  This doesn't work at any kind of scale, so we need
to consider how automation would perform this activity, especially in
light of the fact that it doesn't trust the device it is configuring
yet.

> 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.
> 
> Joseph
> 
> > Are we also planning on providing attestation information over Redfish?
> >
> 

-- 
Patrick Williams

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

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

[Patrick Williams]

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

On Tue, Sep 06, 2022 at 04:05:19AM -0400, Michael Richardson wrote:
> Joseph Reynolds <jrey@linux.ibm.com> wrote:
>     > 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.

Yes, there is already Rust support in bitbake/Yocto.  It has been
available since probably Dunfell.

-- 
Patrick Williams

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

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

[Patrick Williams]

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

On Fri, Sep 02, 2022 at 07:07:58PM +0300, Thore Sommer wrote:
> > My understanding is that keylime is being rewritten in Rust.
> 
> The Keylime agent is rewritten in Rust and the plan is that it will
> become the official agent over the next couple of months.
> The tracking issue can be found here:
> https://github.com/keylime/keylime/issues/986
> 
> The server components are in Python and there is currently no plan to
> change that.

Thank you for the info Thore.  The agent is the most important piece to
us on this effort.  The server side (verifier) typically has a lot more
flexibility in what software stack it can run.

-- 
Patrick Williams

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

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

[Patrick Williams]

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

On Mon, Sep 05, 2022 at 01:59:56PM -0500, Joseph Reynolds wrote:
> On 9/1/22 6:27 AM, Patrick Williams wrote:
> > On Wed, Aug 31, 2022 at 01:09:10PM -0500, Joseph Reynolds wrote:
> >
> >> 2  Proposal for dynamic changes to Redfish authorization rules
> >> https://gerrit.openbmc.org/c/openbmc/docs/+/56401
> >> <https://gerrit.openbmc.org/c/openbmc/docs/+/56401>
> >>
> >> No discussion.
> > Does "no discussion" mean?
> >     - This topic was not covered.
> >     - Nobody present seemed to have an opinion.
> >     - Everyone present was onboard with it as-is.
> >
> > I'm trying to gauge where consensus is at.
> 
> I use "no discussion" when the topic was introduces and described, but 
> nobody expressed any interest or asked any questions.  I think someone 
> asked for the review link, which was already in the agenda. <-- Is there 
> a better way I could say this in the meeting minutes?
> When an agenda item is skipped or omitted from the meeting, I'll put 
> something like "the following topics were not covered" with the reason why.

Thank you for the clarification.

I assumed it was either 2 or 3 from my list above.  Sounds like you are
using "no discussion" to mean 2.

-- 
Patrick Williams

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

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

[Michael Richardson]

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


Patrick Williams <patrick@stwcx.xyz> wrote:
    > I could be wrong on Keylime.  My initial reaction is that it is going
    > to be difficult to get a broad install base on the Verifier side.

Presumably customer that want to have measured boot for their BMC have the
incentive to install such a system.  I know that IBM has sufficiently people
involved with TCG that they ought to already have product that can do this,
but I don't know the product names.

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




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

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

[George Almasi]

 > 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.

Thank you for the reference document. To the extent I can tell, the 
current keylime verifier implements the picture in Section 3 
(Architectural Overview) fairly accurately, at least up to "attestation 
results". And yes, it does use nonces -- replay attacks are ugly.

Keylime is slightly older than the referenced document, so some of the 
things explicit in the diagram are less than obvious. However, when we 
implemented remote measured boot attestation support for keylime, we 
took care to separate reference values from appraisal policy.

>      > 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.
That is what we are hoping to get an agreement on. In preliminary 
discussions with the keylime developers, it might be possible to operate 
the keylime agent as a library, built into someone else's REST service 
(e.g. redfish). But *not right away*. So the idea is to get going with 
keylime operating as a standalone basis at least initially.
>      > 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.
>
We never seriously considered using the keylime Python agent on OpenBMC. 
The requirements in software depdencencies, CPU usage, RAM, _you name 
it_ are horrendous. Rust it is, for a few MBytes of RAM usage (the 
stripped binary is 24MB on my Intel box).

-- George