Request new repo for IBM-specific code

Request new repo for IBM-specific code

[Joseph Reynolds]

What is the right repository for a new Linux-PAM module to implement an 
IBM-specific ACF authentication?

The access control file (ACF) design was introduced to the OpenBMC 
security working group and is described in [IBM issue 1737][] and 
further explained in [IBM issue 2562][].

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.

Can we create a new OpenBMC repo for this?  Perhaps ibm-pam-acf?  Or 
should this go into some other repo?

- Joseph

[IBM issue 1737]: https://github.com/ibm-openbmc/dev/issues/1737
[IBM issue 2562]: https://github.com/ibm-openbmc/dev/issues/2562
[pam-ipmi modules]: https://github.com/openbmc/pam-ipmi

Re: Request new repo for IBM-specific code

[Patrick Williams]

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

On Thu, Mar 04, 2021 at 09:14:47PM -0600, Joseph Reynolds wrote:
> What is the right repository for a new Linux-PAM module to implement an 
> IBM-specific ACF authentication?
> 
> The access control file (ACF) design was introduced to the OpenBMC 
> security working group and is described in [IBM issue 1737][] and 
> further explained in [IBM issue 2562][].

I'm not really seeing much documentation on this in either issue.  Do
you have a document describing your requirements and how you're planning
to accomplish it?

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.

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

> Can we create a new OpenBMC repo for this?  Perhaps ibm-pam-acf?  Or 
> should this go into some other repo?
> 
> - Joseph
> 
> [IBM issue 1737]: https://github.com/ibm-openbmc/dev/issues/1737
> [IBM issue 2562]: https://github.com/ibm-openbmc/dev/issues/2562
> [pam-ipmi modules]: https://github.com/openbmc/pam-ipmi

-- 
Patrick Williams

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

Re: Request new repo for IBM-specific code

[Patrick Williams]

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

On Fri, Mar 05, 2021 at 01:15:47PM -0600, 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.

For more concrete example of what I'm talking about, see 'sshd_config'
options AuthorizePrincipalsCommand and TrustedUserCAKeys.

- An IBM certificate would be the CA for TrustedUserCAKeys (and
  installed on only IBM Enterprise systems.
- AuthorizedPrincipalsCommand would be a small dbus lookup to get
  the system serial number.

Your login credentials would be a certificate signed by the IBM CA where
the system serial number is included in the Principals of the cert.  The
certificate can be set to expire in 24 hours.

I'm pretty sure SSH certificates can be standard X.509 certificates
which can be used for mTLS in a similar way.  bmcweb could be configured
to do similar operations as already built in to SSH.

I don't know if you would want to install the CA and configuration with
a bbappend in your own layer or via a local.conf override on your build
system.  You might want to look at
meta-phosphor/classes/phosphor-deploy-ssh-keys.bbclass as a method of
installing extensions, like SSH keys, in a build.

-- 
Patrick Williams

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

Re: Request new repo for IBM-specific code

[Joseph Reynolds]

On 3/5/21 1:15 PM, Patrick Williams wrote:
> On Thu, Mar 04, 2021 at 09:14:47PM -0600, Joseph Reynolds wrote:
>> What is the right repository for a new Linux-PAM module to implement an
>> IBM-specific ACF authentication?
>>
>> The access control file (ACF) design was introduced to the OpenBMC
>> security working group and is described in [IBM issue 1737][] and
>> further explained in [IBM issue 2562][].
> I'm not really seeing much documentation on this in either issue.  Do
> you have a document describing your requirements and how you're planning
> to accomplish it?

Patrick, thanks for your response!  You are correct I did not motivate 
this very well.  The short answer is twofold:
1. IBM service reps need password authentication: that is how they will 
access the BMC.  They work in a variety of environments, some of which 
do not allow them to carry a certificate to the BMC.
2. Each service call requires an unique password which is enabled by a 
digital certificate.  There is nothing secret in the certificate, so an 
admin may install it on the BMC.

Thus, the flow is for the service rep to generate a certificate (and its 
accompanying password), work with the BMC admin to install the cert onto 
the BMC, and then use the password to authenticate to the BMC.  Password 
authentication steps for the service user are detailed in issue 2562 
cited above.

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

- Joseph

>> Can we create a new OpenBMC repo for this?  Perhaps ibm-pam-acf?  Or
>> should this go into some other repo?
>>
>> - Joseph
>>
>> [IBM issue 1737]: https://github.com/ibm-openbmc/dev/issues/1737
>> [IBM issue 2562]: https://github.com/ibm-openbmc/dev/issues/2562
>> [pam-ipmi modules]: https://github.com/openbmc/pam-ipmi

Re: Request new repo for IBM-specific code

[Ed Tanous]

On Thu, Mar 4, 2021 at 7:15 PM Joseph Reynolds <jrey@linux.ibm.com> wrote:
>
> What is the right repository for a new Linux-PAM module to implement an
> IBM-specific ACF authentication?
>
> The access control file (ACF) design was introduced to the OpenBMC
> security working group and is described in [IBM issue 1737][] and
> further explained in [IBM issue 2562][].

Could you describe it in a design doc?  Implementing ACL seems like
something that's going to affect a lot of the system (at a minimum
every outward facing client).  Unless you really think that you can do
this with no changes to the client repos or phosphor-user-manager, it
seems like it's worth discussion.  For what it's worth, I really don't
want to branch the authorization code in bmcweb depending on what
company compiled the code.  They were hard enough to get right in the
general case, and matter a lot for security.  The likelihood we get
them right for every flavor of auth that a company might want to do
seems unlikely.  If we as a project need an "ultra user" that seems
like it shouldn't be specific to IBM, or should be a generic
configuration that IBM systems apply on top, using common routines.
I've already detailed a path toward this in a previous email on this
topic.

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

Have you released the specifications for this file format with an
appropriate license?  That seems like a good first step to figuring
out if these could find a home in OpenBMC.  If you've already done
that, could you link them?

>
> Can we create a new OpenBMC repo for this?  Perhaps ibm-pam-acf?  Or
> should this go into some other repo?

Could you please post the code you're planning on putting there
somewhere that we can see it in gerrit?  I suspect that would help
review whether or not a new repo is warranted, and probably give hints
as to what design you're planning on implementing.




>
> - Joseph
>
> [IBM issue 1737]: https://github.com/ibm-openbmc/dev/issues/1737
> [IBM issue 2562]: https://github.com/ibm-openbmc/dev/issues/2562
> [pam-ipmi modules]: https://github.com/openbmc/pam-ipmi

Re: Request new repo for IBM-specific code

[Joseph Reynolds]

On 3/8/21 10:03 AM, Ed Tanous wrote:
> On Thu, Mar 4, 2021 at 7:15 PM Joseph Reynolds <jrey@linux.ibm.com> wrote:
>> What is the right repository for a new Linux-PAM module to implement an
>> IBM-specific ACF authentication?
>>
>> The access control file (ACF) design was introduced to the OpenBMC
>> security working group and is described in [IBM issue 1737][] and
>> further explained in [IBM issue 2562][].
> Could you describe it in a design doc?

It would be an IBM-specific design, specific to IBM Enterprise systems.  
We're still working out the design.  I think I can share big parts of it 
with OpenBMC.

> Implementing ACL seems like
> something that's going to affect a lot of the system (at a minimum
> every outward facing client).  Unless you really think that you can do
> this with no changes to the client repos or phosphor-user-manager, it
> seems like it's worth discussion.

I anticipate the implementation would affect OpenBMC in three places:
1. New REST APIs to upload the ACF certificate, under URI /ibm/v1.
2. New Linux-PAM modules to validate the service login, along with 
enhanced /etc/pam.d/ config files for IBM Enterprise systems.
3. New Redfish role Oem.IBM.ServiceAgent (see comment below).

> For what it's worth, I really don't
> want to branch the authorization code in bmcweb depending on what
> company compiled the code.  They were hard enough to get right in the
> general case, and matter a lot for security.  The likelihood we get
> them right for every flavor of auth that a company might want to do
> seems unlikely.  If we as a project need an "ultra user" that seems
> like it shouldn't be specific to IBM, or should be a generic
> configuration that IBM systems apply on top, using common routines.

The BMCWeb pieces are:
1. A new Redfish role: Oem.IBM.ServiceAgent.
2. A new Redfish privilege: Oem.IBM.ProvideService.  For example, allows 
you to PATCH EEPROM data.
3. Implement the Redfish (new in Redfish 2020.4) RestrictedRoles and 
Restricted privileges.

> I've already detailed a path toward this in a previous email on this
> topic.

Thanks, I believe we have agreed on a path forward.

>
>> 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.
> Have you released the specifications for this file format with an
> appropriate license?  That seems like a good first step to figuring
> out if these could find a home in OpenBMC.  If you've already done
> that, could you link them?
>
>> Can we create a new OpenBMC repo for this?  Perhaps ibm-pam-acf?  Or
>> should this go into some other repo?
> Could you please post the code you're planning on putting there
> somewhere that we can see it in gerrit?  I suspect that would help
> review whether or not a new repo is warranted, and probably give hints
> as to what design you're planning on implementing.

[Addressing both comment blocs above:]  I am investigating open sourcing 
the entire set of tools: ACF create/display/validate.
I plan to push the Linux-PAM module for early review as soon as 
possible, and it will reveal the content of the ACF.

Thanks!

> - Joseph
>
> [IBM issue 1737]: https://github.com/ibm-openbmc/dev/issues/1737
> [IBM issue 2562]: https://github.com/ibm-openbmc/dev/issues/2562
> [pam-ipmi modules]: https://github.com/openbmc/pam-ipmi

Re: Request new repo for IBM-specific code

[Patrick Williams]

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

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 Williams

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

Re: Request new repo for IBM-specific code - pam_2fa discussion

[Joseph Reynolds]

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

Re: Request new repo for IBM-specific code - pam_2fa discussion

[Patrick Williams]

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

On Mon, Mar 08, 2021 at 02:30:26PM -0600, Joseph Reynolds wrote:
> 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?

I might have poorly explained my thought process before.  I know
*normal* 2FA requires remote access to the 2FA server.  The PAM_2FA
allows configuration of the URL and there is no reason why the URL
cannot be a localhost implementation of the 2FA protocol.  All the
protocol does is POST to the URL and make a decision based on the HTTP
return code.

Proposal:
    * Use 'pam_2fa' using Yubikey protocol to point at a 'localhost' URL.
    * Implement Yubikey 2FA protocol (described in pam_2fa
      documentation) in a small daemon on the BMC, specific for ACF
      certificates.
        - 2FA request will get the ACF password.
        - ACF daemon hashes password, checks with installed certificate
          and returns 4xx/2xx codes as appropriate.
    * Set PAM config to use 'pam_2fa' (pointed at localhost) for IBM
      service users.

In summary, the service accounts can have a static primary password AND
an ACF-secured secondary password which is checked with the standard 2FA
protocol.

> The IBM ACF design in terms of 2FA is:
...
> 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.

Doesn't the service user have access you're not expecting the 'admin' to
be able to have on your machines?  How do you ensure a compromised ACF
cannot be replayed onto another machine?  With admin-level access it is
fairly trivial to fake out the serial number.

I might be misunderstanding something with "... or ther service rep".
It seems like there is a gap in how the service rep would install
something when the ACF is what gives them permissions to do the install?

-- 
Patrick Williams

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

Re: Request new repo for IBM-specific code - pam_2fa discussion

[Joseph Reynolds]

On 3/8/21 4:41 PM, Patrick Williams wrote:
> On Mon, Mar 08, 2021 at 02:30:26PM -0600, Joseph Reynolds wrote:
>> 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?
> I might have poorly explained my thought process before.  I know
> *normal* 2FA requires remote access to the 2FA server.  The PAM_2FA
> allows configuration of the URL and there is no reason why the URL
> cannot be a localhost implementation of the 2FA protocol.  All the
> protocol does is POST to the URL and make a decision based on the HTTP
> return code.
>
> Proposal:
>      * Use 'pam_2fa' using Yubikey protocol to point at a 'localhost' URL.
>      * Implement Yubikey 2FA protocol (described in pam_2fa
>        documentation) in a small daemon on the BMC, specific for ACF
>        certificates.
>          - 2FA request will get the ACF password.
>          - ACF daemon hashes password, checks with installed certificate
>            and returns 4xx/2xx codes as appropriate.
>      * Set PAM config to use 'pam_2fa' (pointed at localhost) for IBM
>        service users.

Thanks again.  I see it now.  This could work for IBM ACFs.

Your proposal is:
Instead of writing a new Linux-PAM module which checks the password with 
the ACF, this proposal uses pam_2fa.so together with a new BMC-hosted 
HTTPS server (implemented as a new systemd service) which checks the 
password with the ACF.  Instead of putting the checks into my new 
proposed Linux-PAM module, I would put them into the HTTPS REST API server.

I'm not sure what advantage this would give.  It seems like this gives 
me a tested PAM module in exchange for implementing a REST API server.  
I'm not sure I want to make that trade.  The Linux-PAM coding aspects of 
my proposed module are well-understood and straightforward.

> In summary, the service accounts can have a static primary password AND
> an ACF-secured secondary password which is checked with the standard 2FA
> protocol.
>
>> The IBM ACF design in terms of 2FA is:
> ...
>> 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.
> Doesn't the service user have access you're not expecting the 'admin' to
> be able to have on your machines?  How do you ensure a compromised ACF
> cannot be replayed onto another machine?  With admin-level access it is
> fairly trivial to fake out the serial number.

Yes, on IBM Enterprise machines, service access is a superset of admin 
access.  In particular, the interface to change an existing machine 
serial number requires service access.  However, it remains possible for 
a machine owner to use shenanigans to change serial numbers.  This, plus 
the admin's ability to record the service user password and to change 
the BMC's TOD would give them the ability to re-use an ACF.

> I might be misunderstanding something with "... or ther service rep".
> It seems like there is a gap in how the service rep would install
> something when the ACF is what gives them permissions to do the install?

You are correct.  I didn't explain scenarios.

First, note the proposed REST API to install the ACF requires admin 
authority.  There are multiple alternate workflows:
1. A security conscious system owner would have the admin install the 
ACF immediately before service and remove it immediately afterward.  And 
probably look over the service agent's shoulder.
2. A trusting system owner would share admin access with the service 
agent who would install and remove the ACF on behalf of the owner.
3. A forgetful system owner would not have admin access (having lost the 
password).  In this case the service agent asserts physical presence to 
open a time window in which they could upload the ACF without 
authentication or authority needed.

Joseph

Re: Request new repo for IBM-specific code

[Joseph Reynolds]

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

Let's restart this thread from where we left off.  I am working on an 
IBM-specific design to explain the BMC portions of the IBM ACF design to 
the OpenBMC community.

For item 1 ("is the ACF design a secure method"), we discussed an 
abbreviated threat model in this email thread.  From the service 
organizations point of view, it only allows authorized service reps into 
the service account.  And from the BMC admin's point of view, they can 
either lock out or authorize the service user via how they handle the 
ACFm but they don't know the password so they cannot login to the 
service account.
The ACF features including its digital signature, matching system serial 
number, and expiration date -- all of these limit which ACFs a BMC will 
accept.  The new Linux-PAM module login is a straightforward decoding 
and validation of the ACF, and then checking the password hash.  We 
discussed using pam_2fa in this email thread, and I believe it only 
trades the complexity of a PAM module (which I regard as 
straightforward) for the complexity of a REST server.

For item 2 ("is it useful to anyone else"), the answer is no.  This will 
ever only be useful to IBM and to vendors who clone OpenPOWER systems 
including IBM's approach to service account access.

So ... does the GitHub OpenBMC organization host vendor specific repos 
(perhaps github.com/openbmc/ibm-misc), or does the source code go 
somewhere else (such as IBM's public fork in 
github.com/ibm-openbmc/pam-ibm-acf)?

- Joseph

Re: Request new repo for IBM-specific code

[Ed Tanous]

On Thu, Apr 29, 2021 at 2:10 PM Joseph Reynolds <jrey@linux.ibm.com> wrote:
>
> 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.
> ...snip...
>
> Let's restart this thread from where we left off.  I am working on an
> IBM-specific design to explain the BMC portions of the IBM ACF design to
> the OpenBMC community.
>
> For item 1 ("is the ACF design a secure method"), we discussed an
> abbreviated threat model in this email thread.  From the service
> organizations point of view, it only allows authorized service reps into
> the service account.  And from the BMC admin's point of view, they can
> either lock out or authorize the service user via how they handle the
> ACFm but they don't know the password so they cannot login to the
> service account.
> The ACF features including its digital signature, matching system serial
> number, and expiration date -- all of these limit which ACFs a BMC will
> accept.  The new Linux-PAM module login is a straightforward decoding
> and validation of the ACF, and then checking the password hash.  We
> discussed using pam_2fa in this email thread, and I believe it only
> trades the complexity of a PAM module (which I regard as
> straightforward) for the complexity of a REST server.
>
> For item 2 ("is it useful to anyone else"), the answer is no.  This will
> ever only be useful to IBM and to vendors who clone OpenPOWER systems
> including IBM's approach to service account access.
>
> So ... does the GitHub OpenBMC organization host vendor specific repos
> (perhaps github.com/openbmc/ibm-misc), or does the source code go
> somewhere else (such as IBM's public fork in
> github.com/ibm-openbmc/pam-ibm-acf)?

FYI, both of these return 404.  I'm assuming the permissions don't
make them public yet.

>
> - Joseph
>

Re: Request new repo for IBM-specific code

[Joseph Reynolds]

On 4/29/21 4:24 PM, Ed Tanous wrote:
> On Thu, Apr 29, 2021 at 2:10 PM Joseph Reynolds <jrey@linux.ibm.com> wrote:
>> 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.
>> ...snip...
>>
>> Let's restart this thread from where we left off.
...snip
>>
>> So ... does the GitHub OpenBMC organization host vendor specific repos
>> (perhaps github.com/openbmc/ibm-misc), or does the source code go
>> somewhere else (such as IBM's public fork in
>> github.com/ibm-openbmc/pam-ibm-acf)?
> FYI, both of these return 404.  I'm assuming the permissions don't
> make them public yet.

I provided those URLs as concrete suggestions for where to host 
vendor-specific code.  They do not exist.  Sorry about the confusion.  
It is late in the day....:)
I have a weak preference to host ibm-specific code on 
github.com/openbmc/meta-ibm (maybe in subdirectory pam-ibmacf).  I 
realize this will set a precedent for the OpenBMC project, and can work 
either way.

-Joseph

>
>> - Joseph
>>

Re: Request new repo for IBM-specific code

[Patrick Williams]

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

On Thu, Apr 29, 2021 at 04:09:58PM -0500, Joseph Reynolds wrote:
 
> So ... does the GitHub OpenBMC organization host vendor specific repos 
> (perhaps github.com/openbmc/ibm-misc), or does the source code go 
> somewhere else (such as IBM's public fork in 
> github.com/ibm-openbmc/pam-ibm-acf)?

I'm strongly opposed to dumping-ground repositories like
"<company>-misc".  We approved exactly one of those and the rationale we
were given was they had a bunch of existing code they were going to work
at getting upstreamed, but wanted a place to be able to interact with
their vendors in the interrim.  We should not be having *new* code going
into that or any other "misc" repository.

We have generally not wanted OpenBMC-oriented code in non-openbmc-org
repositories that are then picked up by openbmc/openbmc recipes.  If you
have a generally applicable library that isn't tied to openbmc in any
way, or especially one that already has good usage outside of openbmc,
then another github org seems reasonable.  That isn't what you have
here.

It sounds like you have a good definition here of what you want to do,
so I'm fine with `openbmc/pam-ibm-acf`.  I don't see any reason we
cannot host `openbmc/<company>-<feature>` repositories for things which
are company specific, as long as those repositories are only picked up
by your meta-<company> layer.

[[ 
   I think is / will be additional work going on in the background to
   come to better consensus and document any rules around repository
   creation.  This is my current opinion.
]]

-- 
Patrick Williams

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

Re: Request new repo for IBM-specific code: ibm-acf

[Joseph Reynolds]

On 4/30/21 8:29 AM, Patrick Williams wrote:
> On Thu, Apr 29, 2021 at 04:09:58PM -0500, Joseph Reynolds wrote:
>   
>> So ... does the GitHub OpenBMC organization host vendor specific repos
>> (perhaps github.com/openbmc/ibm-misc), or does the source code go
>> somewhere else (such as IBM's public fork in
>> github.com/ibm-openbmc/pam-ibm-acf)?
> I'm strongly opposed to dumping-ground repositories like
> "<company>-misc".  We approved exactly one of those and the rationale we
> were given was they had a bunch of existing code they were going to work
> at getting upstreamed, but wanted a place to be able to interact with
> their vendors in the interrim.  We should not be having *new* code going
> into that or any other "misc" repository.
>
> We have generally not wanted OpenBMC-oriented code in non-openbmc-org
> repositories that are then picked up by openbmc/openbmc recipes.  If you
> have a generally applicable library that isn't tied to openbmc in any
> way, or especially one that already has good usage outside of openbmc,
> then another github org seems reasonable.  That isn't what you have
> here.
>
> It sounds like you have a good definition here of what you want to do,
> so I'm fine with `openbmc/pam-ibm-acf`.  I don't see any reason we
> cannot host `openbmc/<company>-<feature>` repositories for things which
> are company specific, as long as those repositories are only picked up
> by your meta-<company> layer.

Patrick,

Thanks.  That works for me.  I propose a new repo ibm-acf which will 
have 4 related parts:
1. The Linux-PAM pam_ibmacf module (targeted to run on the BMC)
2. A tool to create and read ACF files (targeted to run on the build host)
3. Common source library for use by the two items above and by the BMC's 
function to upload & validate an ACF file.
4. Absolutely minimal test cases and documentation.

The idea is the meta-ibm layer could optionally pick up the pam_ibmacf 
piece and configure it into the Linux-PAM stack, then the tester can 
create or inject a key pair, and use the provided tool to create an ACF 
file for upload to the BMC.

Joseph

> [[
>     I think is / will be additional work going on in the background to
>     come to better consensus and document any rules around repository
>     creation.  This is my current opinion.
> ]]
>

Re: Request new repo for IBM-specific code: ibm-acf

[Andrew Jeffery]

On Sat, 1 May 2021, at 15:00, Joseph Reynolds wrote:
> On 4/30/21 8:29 AM, Patrick Williams wrote:
> > On Thu, Apr 29, 2021 at 04:09:58PM -0500, Joseph Reynolds wrote:
> >   
> >> So ... does the GitHub OpenBMC organization host vendor specific repos
> >> (perhaps github.com/openbmc/ibm-misc), or does the source code go
> >> somewhere else (such as IBM's public fork in
> >> github.com/ibm-openbmc/pam-ibm-acf)?
> > I'm strongly opposed to dumping-ground repositories like
> > "<company>-misc".  We approved exactly one of those and the rationale we
> > were given was they had a bunch of existing code they were going to work
> > at getting upstreamed, but wanted a place to be able to interact with
> > their vendors in the interrim.  We should not be having *new* code going
> > into that or any other "misc" repository.
> >
> > We have generally not wanted OpenBMC-oriented code in non-openbmc-org
> > repositories that are then picked up by openbmc/openbmc recipes.  If you
> > have a generally applicable library that isn't tied to openbmc in any
> > way, or especially one that already has good usage outside of openbmc,
> > then another github org seems reasonable.  That isn't what you have
> > here.
> >
> > It sounds like you have a good definition here of what you want to do,
> > so I'm fine with `openbmc/pam-ibm-acf`.  I don't see any reason we
> > cannot host `openbmc/<company>-<feature>` repositories for things which
> > are company specific, as long as those repositories are only picked up
> > by your meta-<company> layer.
> 
> Patrick,
> 
> Thanks.  That works for me.  I propose a new repo ibm-acf which will 
> have 4 related parts:
> 1. The Linux-PAM pam_ibmacf module (targeted to run on the BMC)
> 2. A tool to create and read ACF files (targeted to run on the build host)
> 3. Common source library for use by the two items above and by the BMC's 
> function to upload & validate an ACF file.
> 4. Absolutely minimal test cases and documentation.

What? Why? I don't have much context, but I think this needs more justification.

Andrew

Re: Request new repo for IBM-specific code: ibm-acf

[Andrew Jeffery]

On Mon, 3 May 2021, at 09:16, Andrew Jeffery wrote:
> 
> 
> On Sat, 1 May 2021, at 15:00, Joseph Reynolds wrote:
> > On 4/30/21 8:29 AM, Patrick Williams wrote:
> > > On Thu, Apr 29, 2021 at 04:09:58PM -0500, Joseph Reynolds wrote:
> > >   
> > >> So ... does the GitHub OpenBMC organization host vendor specific repos
> > >> (perhaps github.com/openbmc/ibm-misc), or does the source code go
> > >> somewhere else (such as IBM's public fork in
> > >> github.com/ibm-openbmc/pam-ibm-acf)?
> > > I'm strongly opposed to dumping-ground repositories like
> > > "<company>-misc".  We approved exactly one of those and the rationale we
> > > were given was they had a bunch of existing code they were going to work
> > > at getting upstreamed, but wanted a place to be able to interact with
> > > their vendors in the interrim.  We should not be having *new* code going
> > > into that or any other "misc" repository.
> > >
> > > We have generally not wanted OpenBMC-oriented code in non-openbmc-org
> > > repositories that are then picked up by openbmc/openbmc recipes.  If you
> > > have a generally applicable library that isn't tied to openbmc in any
> > > way, or especially one that already has good usage outside of openbmc,
> > > then another github org seems reasonable.  That isn't what you have
> > > here.
> > >
> > > It sounds like you have a good definition here of what you want to do,
> > > so I'm fine with `openbmc/pam-ibm-acf`.  I don't see any reason we
> > > cannot host `openbmc/<company>-<feature>` repositories for things which
> > > are company specific, as long as those repositories are only picked up
> > > by your meta-<company> layer.
> > 
> > Patrick,
> > 
> > Thanks.  That works for me.  I propose a new repo ibm-acf which will 
> > have 4 related parts:
> > 1. The Linux-PAM pam_ibmacf module (targeted to run on the BMC)
> > 2. A tool to create and read ACF files (targeted to run on the build host)
> > 3. Common source library for use by the two items above and by the BMC's 
> > function to upload & validate an ACF file.
> > 4. Absolutely minimal test cases and documentation.
> 
> What? Why? I don't have much context, but I think this needs more justification.

To clarify, "absolutely minimal test cases and documentation" is what I 
what I think needs more justification.

Andrew

Re: Request new repo for IBM-specific code

[Ed Tanous]

On Thu, Apr 29, 2021 at 2:10 PM Joseph Reynolds <jrey@linux.ibm.com> wrote:
>
> 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.
> ...snip...
>
> Let's restart this thread from where we left off.  I am working on an
> IBM-specific design to explain the BMC portions of the IBM ACF design to
> the OpenBMC community.
>
> For item 1 ("is the ACF design a secure method"), we discussed an
> abbreviated threat model in this email thread.  From the service
> organizations point of view, it only allows authorized service reps into
> the service account.  And from the BMC admin's point of view, they can
> either lock out or authorize the service user via how they handle the
> ACFm but they don't know the password so they cannot login to the
> service account.
> The ACF features including its digital signature, matching system serial
> number, and expiration date -- all of these limit which ACFs a BMC will
> accept.  The new Linux-PAM module login is a straightforward decoding
> and validation of the ACF, and then checking the password hash.  We
> discussed using pam_2fa in this email thread, and I believe it only
> trades the complexity of a PAM module (which I regard as
> straightforward) for the complexity of a REST server.
>
> For item 2 ("is it useful to anyone else"), the answer is no.  This will
> ever only be useful to IBM and to vendors who clone OpenPOWER systems
> including IBM's approach to service account access.
>
> So ... does the GitHub OpenBMC organization host vendor specific repos
> (perhaps github.com/openbmc/ibm-misc), or does the source code go
> somewhere else (such as IBM's public fork in
> github.com/ibm-openbmc/pam-ibm-acf)?
>

Is there a design doc for this yet?  I'm not feeling like there's
enough details on what "ACF" even is to understand whether a new repo
would be warranted, or this is something that we want to support.  I'd
like to understand all the components that we'd expect to change, and
how we can ensure that the abstractions are good enough that we don't
break or cause security vulnerabilities to anyone else that's not
using this feature.

> - Joseph
>