Security Working Group meeting - Wednesday September 29

Security Working Group meeting - Wednesday September 29

[Joseph Reynolds]

This is a reminder of the OpenBMC Security Working Group meeting 
scheduled for this Wednesday September 29 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:

1. Continue discussion: Password based auth for IPMI over DTLS 
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/31548 
<https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/31548>
2. (Joseph) Who wants a function to enable/disable BMC USB ports? 
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/47180 
<https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/47180>



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 September 29

[Joseph Reynolds]

On 9/28/21 8:35 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday September 29 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:
>
> 1. Continue discussion: Password based auth for IPMI over DTLS 
> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/31548 
> <https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/31548>

DISCUSSION:

The planned IPMI over DLTS function will have certificate-based 
authuentication.  For our use cases, we would like to add password-based 
authentication, and we want to do so as securely as possible, meaning 
what protocol we should use.  In particular, we want to know if we 
should avoid sending a “cleartext” password (tunneled over DTLS) to the 
server.

However note the Redfish password authentication passes in the cleartext 
password to the Redfish/HTTP server (tunneled over HTTPS). Does not need 
the existing ipmi_pass file, or will at least store the password 
securely in it.

Contrast with Redfish password change and with Basic Auth.

Consider RAKP which does not require the password to be transmitted in 
cleartext.

Can we use consider SRP (dropped in OpenSSL 3.0 -- why?) or other 
implementations such as GnuTLS?

Want to know what protocol to use for password auth over DTLS.  And then 
implement it correctly.

TODO: Call for experts to weigh on.

> 2. (Joseph) Who wants a function to enable/disable BMC USB ports? 
> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/47180 
> <https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/47180> 
>

What does disable USB port mean?  USB for BMC use.  [Discussion excludes 
host USB ports, and any USB ports further from the BMC.]

DISCUSSION:

Threats: USB protocol attack, power-based attack, epoxy-based DoS 
attacks, use of functions built on top of USB function.

Can disable ports independently: Does Redfish want to model topology?  
Sets of USB ports, such as those with physical external connectors, and 
internal.  ANSWER: Yes, see below.

Need to model topology (machine architecture, USB hubs, etc.) as part of 
understanding the issues?  Or can we partition USB ports and call it 
either BMC or host?

Consider essential connections such as USB-based BMC keyboards, 
USB-based BMC/host connections, etc.

The design is interested specifically in used-by-BMC external-to-the-box 
USB ports.

Note that if USB ports are needed for BMC recovery (such as a USB key), 
then disabling the USB will remove that recovery option.

Note: The U-Boot is an independent OS which may have access to a 
“disabled” BMC.

Where to disable USB ports?  In OpenBMC kernel?  In Uboot kernel (does 
not have support for USB?)?  Via pgood gpio?

What does the Redfish endpoint control?  TODO: Joseph to investigate.  
DONE:  After the meeting.  Notes:

Summary: Redfish models USB Controllers (as USBController),  USB Port 
Collections (as PortCollection), and USB Ports (as Port).  
Implementations who want to implement powering off ports can use the 
USBController Resource_PowerState schema.  Implementations who want to 
disable USB ports can use the USBController Resource_State schema or the 
Port Enabled property.


DETAILS: A Redfish USBController:

http://redfish.dmtf.org/schemas/v1/USBController.v1_0_0.yaml#/components/schemas/USBController_v1_0_0_USBController 
<http://redfish.dmtf.org/schemas/v1/USBController.v1_0_0.yaml#/components/schemas/USBController_v1_0_0_USBController>where 
properties include: Ports (PortCollection), Status (which can have a 
Resource_PowerState schema or a Resource_State schema (includes 
enabled/disabled))

Ref: https://redfish.dmtf.org/schemas/PortCollection.yaml 
<https://redfish.dmtf.org/schemas/PortCollection.yaml>has property 
Members which somehow presumably can get to a 
https://redfish.dmtf.org/schemas/Port.yaml 
<https://redfish.dmtf.org/schemas/Port.yaml>where Port_v1_5_0_Port has 
an “Enabled” property.


Do we need a custom OEM solution?

How do testers check if a USB port is disabled?  Power?  Signals?



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

SPAKE, DTLS and passwords

[Michael Richardson]

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


Joseph Reynolds <jrey@linux.ibm.com> wrote:
    > The planned IPMI over DLTS function will have certificate-based
    > authuentication. 

Do you mean that the server will be authenticated with a certificate, or that
it will use mutual authentication?

    > For our use cases, we would like to add password-based
    > authentication, and we want to do so as securely as possible, meaning what
    > protocol we should use.  In particular, we want to know if we should avoid
    > sending a “cleartext” password (tunneled over DTLS) to the server.

If it can be avoided, yes.

https://www.rfc-editor.org/rfc/rfc8125.html#section-3.1 suggests that all
the PAKE candidates (whether balanced or augmented) satisfy this.
I strongly suggest that a PAKE be used.
The CHIP/MATTER IoT people are using
   https://datatracker.ietf.org/doc/draft-bar-cfrg-spake2plus/
although the IRTF CFRG hasn't adopted that document yet.  I don't know
exactly where they are with it.  But, I expect you will find many libraries
going forward.

    > However note the Redfish password authentication passes in the cleartext
    > password to the Redfish/HTTP server (tunneled over HTTPS). Does not need the
    > existing ipmi_pass file, or will at least store the password securely in it.

When the password is set, it can be set into two different hashed forms if necessary.

There are two concerns that I think this description deals with.

The first is:
  a) possibility that a cleartext password will be intercepted via
     Onpath active attack to the connection. (a "MITM")

The second is:
  b) possibility that a cleartext password will be recovered from the
     target system's authentication database.


Whether or not (a) is likely depends very much on whether or not the BMC will
be provisioned or onboarded with useful certificates that the clients can
actually validate.   If the operational uses of IPMI-DTLS and HTTPS APIs
are regularly skipping certificate validation, then it's probably important
that this does not result in a password capture.

{I said in summer 2020 that I would be writing a BRSKI, RFC8995 client for
BMC. Sometime in fall 2020... but now I'm actually close to saying Winter
2022.  I have many questions about testing this that I'll come back to}

(b) wouldn't be a huge problem if all the passwords are unique.
Afterwall, if an attacker can get a password out of the system, then the
attacker already has access to that system.  If the passwords are unique,
then retrieving that password gets the attacker nothing.

Now, if none of the mechanisms require that a cleartext password be stored on
the system, then (b) is moot.

Best is if no passwords are used, even if they are never transmitted,
but many seem to find this operationally difficult to do.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [





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

Re: SPAKE, DTLS and passwords

[Joseph Reynolds]

On 10/4/21 4:47 PM, Michael Richardson wrote:
> Joseph Reynolds <jrey@linux.ibm.com> wrote:
>      > The planned IPMI over DLTS function will have certificate-based
>      > authuentication.
>
> Do you mean that the server will be authenticated with a certificate, or that
> it will use mutual authentication?

I understand this means mutual-TLS.
Based on the gerrit design: 
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/31548/4/designs/ipmi-over-dtls.md

Note that design also says the server will have an identity certificate; 
same as the HTTPS certificate described in 
https://github.com/openbmc/bmcweb/blob/master/README.md

Joseph

...snip...

> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>
>
>
>

Re: SPAKE, DTLS and passwords

[Michael Richardson]

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


Joseph Reynolds <jrey@linux.ibm.com> wrote:
    > On 10/4/21 4:47 PM, Michael Richardson wrote:
    >> Joseph Reynolds <jrey@linux.ibm.com> wrote:
    >> > The planned IPMI over DLTS function will have certificate-based
    >> > authuentication.
    >>
    >> Do you mean that the server will be authenticated with a certificate, or that
    >> it will use mutual authentication?

    > I understand this means mutual-TLS.
    > Based on the gerrit design:
    > https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/31548/4/designs/ipmi-over-dtls.md

So, why is a password needed?

    > Note that design also says the server will have an identity certificate; same
    > as the HTTPS certificate described in
    > https://github.com/openbmc/bmcweb/blob/master/README.md


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

Re: SPAKE, DTLS and passwords

[Joseph Reynolds]

On 10/5/21 10:09 AM, Michael Richardson wrote:
> Joseph Reynolds <jrey@linux.ibm.com> wrote:
>      > On 10/4/21 4:47 PM, Michael Richardson wrote:
>      >> Joseph Reynolds <jrey@linux.ibm.com> wrote:
>      >> > The planned IPMI over DLTS function will have certificate-based
>      >> > authuentication.
>      >>
>      >> Do you mean that the server will be authenticated with a certificate, or that
>      >> it will use mutual authentication?
>
>      > I understand this means mutual-TLS.
>      > Based on the gerrit design:
>      > https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/31548/4/designs/ipmi-over-dtls.md
>
> So, why is a password needed?

Password-based auth of IPMI over DTLS is wanted to satisfy use cases for 
installations who cannot or will not use mTLS.

The OpenBMC security working group notes may not be entirely clear. Here 
is the larger context:
- mTLS based authentication of IPMI over DTLS [1] is being designed.
- We are discussing protocols for an *optional* password-based 
authentication of IPMI over DTLS.
- Password-based auth of IPMI over DTLS is wanted to satisfy use cases 
for users who cannot or will not use mTLS.
- We haven't discussed if password auth will be enabled by default. I 
assume there would be a compile-time configuration and there will be a 
way to compile it out of the server.

[1]: https://gerrit.openbmc-project.xyz/c/openbmc/docs

-Joseph

>
>      > Note that design also says the server will have an identity certificate; same
>      > as the HTTPS certificate described in
>      > https://github.com/openbmc/bmcweb/blob/master/README.md
>

Re: SPAKE, DTLS and passwords + aPAKE and SCRAM

[Joseph Reynolds]

On 10/4/21 4:47 PM, Michael Richardson wrote:
> Joseph Reynolds <jrey@linux.ibm.com> wrote:
>      > The planned IPMI over DLTS function will have certificate-based
>      > authuentication.
>
> Do you mean that the server will be authenticated with a certificate, or that
> it will use mutual authentication?
>
>      > For our use cases, we would like to add password-based
>      > authentication, and we want to do so as securely as possible, meaning what
>      > protocol we should use.  In particular, we want to know if we should avoid
>      > sending a “cleartext” password (tunneled over DTLS) to the server.
>
> If it can be avoided, yes.
>
> https://www.rfc-editor.org/rfc/rfc8125.html#section-3.1 suggests that all
> the PAKE candidates (whether balanced or augmented) satisfy this.
> I strongly suggest that a PAKE be used.
> The CHIP/MATTER IoT people are using
>     https://datatracker.ietf.org/doc/draft-bar-cfrg-spake2plus/
> although the IRTF CFRG hasn't adopted that document yet.  I don't know
> exactly where they are with it.  But, I expect you will find many libraries
> going forward.
>
Michael, thanks for your reply.  I got feedback from my people (but my 
skillset is too weak to interpret it):

Weakness of SRP (Secure Remote Password):
  - Server spoofing, there is nothing that prevents a server from being 
spoofed.
  - Widely adopted with very little proof of being cryptographically 
secure and has been shown vulnerable to pre-computation attacks

  - No feasible way to check for password complexity in the protocol 
(true for most aPAKE - asymmetric Password Authenticated Key Exchange)
  - Some debate over if actually provides forward secrecy.

Recommendation to look at at OPAQUE aPAKE: 
https://blog.cloudflare.com/opaque-oblivious-passwords/

Suggestion to use SCRAM 
https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism

-Joseph

...snip...

>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>
>
>
>

Re: SPAKE, DTLS and passwords + aPAKE and SCRAM

[Vernon Mauery]

On 05-Oct-2021 10:24 AM, Joseph Reynolds wrote:
>On 10/4/21 4:47 PM, Michael Richardson wrote:
>>Joseph Reynolds <jrey@linux.ibm.com> wrote:
>>     > The planned IPMI over DLTS function will have certificate-based
>>     > authuentication.
>>
>>Do you mean that the server will be authenticated with a certificate, or that
>>it will use mutual authentication?
>>
>>     > For our use cases, we would like to add password-based
>>     > authentication, and we want to do so as securely as possible, meaning what
>>     > protocol we should use.  In particular, we want to know if we should avoid
>>     > sending a “cleartext” password (tunneled over DTLS) to the server.
>>
>>If it can be avoided, yes.
>>
>>https://www.rfc-editor.org/rfc/rfc8125.html#section-3.1 suggests that all
>>the PAKE candidates (whether balanced or augmented) satisfy this.
>>I strongly suggest that a PAKE be used.
>>The CHIP/MATTER IoT people are using
>>    https://datatracker.ietf.org/doc/draft-bar-cfrg-spake2plus/
>>although the IRTF CFRG hasn't adopted that document yet.  I don't know
>>exactly where they are with it.  But, I expect you will find many libraries
>>going forward.
>>
>Michael, thanks for your reply.  I got feedback from my people (but my 
>skillset is too weak to interpret it):
>
>Weakness of SRP (Secure Remote Password):
> - Server spoofing, there is nothing that prevents a server from being 
>spoofed.
> - Widely adopted with very little proof of being cryptographically 
>secure and has been shown vulnerable to pre-computation attacks

> - No feasible way to check for password complexity in the protocol 
>(true for most aPAKE - asymmetric Password Authenticated Key Exchange)
> - Some debate over if actually provides forward secrecy.
>
>Recommendation to look at at OPAQUE aPAKE: 
>https://blog.cloudflare.com/opaque-oblivious-passwords/
>
>Suggestion to use SCRAM https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism

I will add SCRAM and PAKE to my list of things to investigate.

--Vernon

Re: SPAKE, DTLS and passwords

[Vernon Mauery]

On 04-Oct-2021 05:47 PM, Michael Richardson wrote:
>
>Joseph Reynolds <jrey@linux.ibm.com> wrote:
>    > The planned IPMI over DLTS function will have certificate-based
>    > authuentication. 
>
>Do you mean that the server will be authenticated with a certificate, or that
>it will use mutual authentication?

Both. There will be host certificate authentication for all connections 
and then the possibility to authenticate with either password or client 
certificates.

>    > For our use cases, we would like to add password-based
>    > authentication, and we want to do so as securely as possible, meaning what
>    > protocol we should use.  In particular, we want to know if we should avoid
>    > sending a “cleartext” password (tunneled over DTLS) to the server.
>
>If it can be avoided, yes.
>
>https://www.rfc-editor.org/rfc/rfc8125.html#section-3.1 suggests that all
>the PAKE candidates (whether balanced or augmented) satisfy this.
>I strongly suggest that a PAKE be used.
>The CHIP/MATTER IoT people are using
>   https://datatracker.ietf.org/doc/draft-bar-cfrg-spake2plus/
>although the IRTF CFRG hasn't adopted that document yet.  I don't know
>exactly where they are with it.  But, I expect you will find many libraries
>going forward.
>
>    > However note the Redfish password authentication passes in the cleartext
>    > password to the Redfish/HTTP server (tunneled over HTTPS). Does not need the
>    > existing ipmi_pass file, or will at least store the password securely in it.
>
>When the password is set, it can be set into two different hashed forms if necessary.

Whatever password scheme is used, one requirement is that the password 
must be hashed or somehow encrypted securely on the BMC.

I did see PAKE show up in my research on this, but I don't yet 
understand it well enough to make a call on whether to use it or not. 
This is why we are reaching out to the experts. :)

>There are two concerns that I think this description deals with.
>
>The first is:
>  a) possibility that a cleartext password will be intercepted via
>     Onpath active attack to the connection. (a "MITM")
>
>The second is:
>  b) possibility that a cleartext password will be recovered from the
>     target system's authentication database.
>
>
>Whether or not (a) is likely depends very much on whether or not the BMC will
>be provisioned or onboarded with useful certificates that the clients can
>actually validate.   If the operational uses of IPMI-DTLS and HTTPS APIs
>are regularly skipping certificate validation, then it's probably important
>that this does not result in a password capture.

This is a huge issue, given how few people really understand how 
certificates work and the difficulty of working with a pki. We should 
definitely do everything we can to reduce the complexity/difficulty of 
getting a valid host key/certificate in place. But in reality, option a) 
is a valid concern.

>{I said in summer 2020 that I would be writing a BRSKI, RFC8995 client for
>BMC. Sometime in fall 2020... but now I'm actually close to saying Winter
>2022.  I have many questions about testing this that I'll come back to}
>
>(b) wouldn't be a huge problem if all the passwords are unique.
>Afterwall, if an attacker can get a password out of the system, then the
>attacker already has access to that system.  If the passwords are unique,
>then retrieving that password gets the attacker nothing.
>
>Now, if none of the mechanisms require that a cleartext password be stored on
>the system, then (b) is moot.

Even if we do end up sending a tunneled password, I think there is 
consensus that we will not be storing it in the clear. That is one of 
the biggest problems with the current RMCP+ protocol, it requires use 
of the cleartext password on the host side.

--Vernon

Re: Security Working Group meeting - Wednesday September 29

[Michael Richardson]

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


Joseph Reynolds <jrey@linux.ibm.com> wrote:
    > Can we use consider SRP (dropped in OpenSSL 3.0 -- why?) or other
    > implementations such as GnuTLS?

I meant to add/ask:

I assume OpenSSL is part of the build process today.
Would switching to GnuTLS, WolfTLS or MbedTLS really be possible?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


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

Re: Security Working Group meeting - Wednesday September 29

[Bruce Mitchell]

On 10/4/2021 14:49, Michael Richardson wrote:
> 
> Joseph Reynolds <jrey@linux.ibm.com> wrote:
>      > Can we use consider SRP (dropped in OpenSSL 3.0 -- why?) or other
>      > implementations such as GnuTLS?
> 
> I meant to add/ask:
> 
> I assume OpenSSL is part of the build process today.
> Would switching to GnuTLS, WolfTLS or MbedTLS really be possible?
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 
Or LibreSSL https://www.libressl.org/