* Re: Security Working Group meeting - Wednesday September 1 - results
2021-09-01 14:22 ` Joseph Reynolds
@ 2021-09-01 21:34 ` Joseph Reynolds
0 siblings, 0 replies; 3+ messages in thread
From: Joseph Reynolds @ 2021-09-01 21:34 UTC (permalink / raw)
To: openbmc
On 9/1/21 9:22 AM, Joseph Reynolds wrote:
> On 8/31/21 10:19 PM, Joseph Reynolds wrote:
>> This is a reminder of the OpenBMC Security Working Group meeting
>> scheduled for this Wednesday September 1 at 10:00am PDT.
>>
>> We'll discuss the following items on the agenda
>> <https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI/edit>,
>> and anything else that comes up:
Attended: Joseph Reynolds, Milton Miller (attended first half: IPMI over
DTLS topic), James Mihm, Ratan Gupta, Andrei Kartashev, Daniil Engranov,
Dhananjay MSFT, Dick [Phoenix], Jiang Zhang
>>
>> 1.
>>
>> Ratan Gupta wants to join the Security Response Team for NVIDIA.
>> See
>> https://github.com/openbmc/docs/blob/master/security/obmc-security-response-team-guidelines.md#team-composition-and-email-maintenance
>>
>> <https://github.com/openbmc/docs/blob/master/security/obmc-security-response-team-guidelines.md#team-composition-and-email-maintenance>
>>
>>
DISCUSSION:
We discussed some criteria for SRT membership:
*
Although individuals join the SRT, it is really organizations which
join as represented by their SRT members. The SRT member candidate
should be able to affirm that they participate in their company’s SRT.
*
The organization should have a “vested interest” in OpenBMC security
response. Here are some examples to consider:
o
Organizations which use OpenBMC to produce products or services
which are publicly available, and disclose security bugs to
their users. For example, any org which produces systems which
use OpenBMC and have a sufficiently mature SRT.
o
Downstream organizations, for example, who aggregate BMC-based
systems into larger systems.
o
Security research orgs, open source SRTs, etc. which have a
significant interest in BMCs.
*
The default stance should be to deny membership in the SRT. This is
to support the requirement to limit membership so as to not
prematurely disclose security vulnerabilities.
History: The initial SRT membership was the TSC members plus their
delegates.
In UEFI Forum, the founder companies formed the initial SRT, and then
explicitly invited select organizations to join, such as OS orgs like
RedHat and Debian. Call for more orgs who use OpenBMC who fit these
criteria to join the SRT.
> Additional agenda item:
> 2.(gerrit review)
> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/31548
> <https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/31548>IPMI over
> DTLS - questions about basic direction and sharing of private keys
>
2 (gerrit review)
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/31548
<https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/31548>IPMI over
DTLS - questions about use of OpenSSL and sharing of private keys
DISCUSSION:
Structure: The IPMI server and the BMCWeb server belong to the same
BMC. So should they share the same certificate? Or should they have
different certificates because they are different services?
Opinion: Have separate certificates for each service. The BMC admin can
install the same certificate for both, if they wish.
Items to add to the design:
*
Describe certificate management.
*
If DTLS and Redfish share a cert, what happens when the cert changes
because of a Redfish API operation?
*
Talk about how DTLS will configure or consume OpenSSL.
Call to action: please comment in the review.
Let’s invite Ed and Vernon next time if open questions remain from the
gerrit review.
>>
>> 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
>
^ permalink raw reply [flat|nested] 3+ messages in thread