SPAKE, DTLS and passwords

[Michael Richardson <mcr@sandelman.ca>]

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