Re: Security Working Group meeting - Wednesday September 1 - results

[Joseph Reynolds <jrey@linux.ibm.com>]

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
>