SPAKE, DTLS and passwords

[Vernon Mauery]

On 04-Oct-2021 05:47 PM, Michael Richardson wrote:
>
>Joseph Reynolds <jrey at 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