All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Reynolds <jrey@linux.ibm.com>
To: Patrick Williams <patrick@stwcx.xyz>
Cc: openbmc <openbmc@lists.ozlabs.org>
Subject: Re: Request new repo for IBM-specific code - pam_2fa discussion
Date: Mon, 8 Mar 2021 14:30:26 -0600	[thread overview]
Message-ID: <15f3a43c-d876-38e0-8397-9db8a3896d38@linux.ibm.com> (raw)
In-Reply-To: <YEZwz6C5uGk8Vobs@heinlein>

On 3/8/21 12:45 PM, Patrick Williams wrote:
> On Sat, Mar 06, 2021 at 10:09:36PM -0600, Joseph Reynolds wrote:
>> On 3/5/21 1:15 PM, Patrick Williams wrote:
>>> On Thu, Mar 04, 2021 at 09:14:47PM -0600, Joseph Reynolds wrote:
>>> My first reading of what is there, I'm not sure why typical certificate
>>> based authentication couldn't solve your needs (but I'm just guessing
>>> what your needs are).  It seems like you have a root-authority (IBM), a
>>> a daily expiring certificate, and some fields in the certificate you
>>> want to confirm (ex. serial number).  I've seen other production-level
>>> systems doing similar for SSH/HTTPS without additional PAM modules.
>> Our service team requires password based authentication.  Period. And
>> they don't like the idea of having to generate a certificate/password
>> pair for each service call.  But certificates offer the best technology
>> we have to solve the access problem.  And we are not yet prepared to go
>> to a certificate-only solution. ... So this is where we are at.
>>
>>>> Note the [pam-ipmi modules][] are scoped to the OpenBMC project because
>>>> the IPMI implementation is shared by all of OpenBMC.  By comparison, the
>>>> proposed ibm-pam-acf module is intended only for IBM Enterprise
>>>> systems.  The intended implementation is based on standard cryptography
>>>> techniques and could be developed into a general authentication
>>>> solution, but the ACF is specific to IBM in terms of its exact format
>>>> and content, and I expect it will only be used by IBM and its partners.
>>> Are you planning to open up the tools necessary to create these ACFs?
>> No, I hadn't been, but good idea!  We have prototype tools to generate
>> and read the ACF.  They should be useful to our test team.
>> There should be nothing secret in the code.  ("The only secret is the
>> private key.")  I'll check with my security team.
> My two concerns about hosting a repository for this are:
>     1. Is it actually a secure method?
>     2. Is it [potentially] useful to anyone else?
>
> WRT, #1, I think we need more details to make an assessment.
>
> For #2 I think there is some unsettled debate around "what do we do
> about code that is only ever going to be useful to one company"?
> Opening up the tools would at least make it possible that someone else
> could find this useful.  I think the proposed "Repository Review Board"
> might work on better guidance otherwise.
>
> Beyond that, I just have the normal "is this the right way to be doing
> this" questions.  You've answered that somewhat with the Certs.  I may
> disagree with it, but you obviously know your support team better than I
> do.
>
> I recommended some SSH support for certificates before.  Based on your
> ask for password-based authentiation, I would suggest looking into
> pam_2fa[1] as a potential implementation as well.  I know on the surface
> this doesn't sound like 2FA, but the pam_2fa module has some benefits, I
> think, in this scenario:
>      * We avoid writing our own [scary] PAM module.
>      * You pave the way for a much more common use case that others could
>        build on for other scenarios.
> Using pam_2fa, we would only need to make a small localhost-only REST
> daemon to answer the 2fa requests for your service users and not a full
> PAM module.  Your service users would have a static password plus a 2FA
> code (secondary password) populated by whatever this ACF method is.  On
> other installs, we could use a proper 2FA server with slightly different
> configuration to satisfy things like Yubikey-backed 2FA.
>
> 1. https://github.com/CERN-CERT/pam_2fa

Patrick, thanks for that.  I was unaware of the pam_2fa project.  I 
agree this could a be a good way for BMCs to get 2FA.

However, as I tried to state in this email thread, the IBM firmware 
service organization requires that all credentials be brought onto the 
work site because some sites have no way to communicate with an external 
server.  That is, once you are on a customer site, you might not be able 
to call into IBM (or even have access to a phone).  Although this is not 
typical, I don't think it is unique to IBM.  What is done other secure 
installations?

The IBM ACF design in terms of 2FA is:
1. For each service call, the IBM service rep generates an unique ACF 
certificate and its associated password, using a secure server within 
IBM.  The ACF and its password are the two factors.
2. The ACF has no secrets (other than the password hash stored within 
it) and can be installed onto the BMC by the admin or the service rep.
3. The BMC itself validates the ACF's signature.  This validates the 
first authentication factor.
4. When the service user requests authentication, the BMC validates the 
password with the ACF password hash.  This validates the second 
authentication factor.

Per concern 1 above:
A. Only IBM can sign the ACF and only IBM can install the corresponding 
public key into the BMC.  So only IBM can authorize service reps.  (Note 
this solution can be directly re-used by other organizations.)
B. Note the password hash is readable by the BMC admin.  It is possible 
the hash could be cracked offline.  That (coupled with the ability 
change the BMC TOD) would give service access against IBM's wishes.

Joseph


  reply	other threads:[~2021-03-08 20:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05  3:14 Request new repo for IBM-specific code Joseph Reynolds
2021-03-05 19:15 ` Patrick Williams
2021-03-05 22:05   ` Patrick Williams
2021-03-07  4:09   ` Joseph Reynolds
2021-03-08 18:45     ` Patrick Williams
2021-03-08 20:30       ` Joseph Reynolds [this message]
2021-03-08 22:41         ` Request new repo for IBM-specific code - pam_2fa discussion Patrick Williams
2021-03-09 17:43           ` Joseph Reynolds
2021-04-29 21:09       ` Request new repo for IBM-specific code Joseph Reynolds
2021-04-29 21:24         ` Ed Tanous
2021-04-30  0:47           ` Joseph Reynolds
2021-04-30 13:29         ` Patrick Williams
2021-05-01  5:30           ` Request new repo for IBM-specific code: ibm-acf Joseph Reynolds
2021-05-02 23:46             ` Andrew Jeffery
2021-05-03  1:37               ` Andrew Jeffery
2021-05-03 16:21         ` Request new repo for IBM-specific code Ed Tanous
2021-03-08 16:03 ` Ed Tanous
2021-03-08 17:30   ` Joseph Reynolds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=15f3a43c-d876-38e0-8397-9db8a3896d38@linux.ibm.com \
    --to=jrey@linux.ibm.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=patrick@stwcx.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.