Survey for Certificate Management Needs

Survey for Certificate Management Needs

[Richard Hanley]

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

Hi Everyone,

We've been having a lot of internal discussions about how we want to manage
certificates/credentials on a BMC out of band. I wanted to get an idea
about what we broadly need as a community, and if it matches some of our
needs.

For authentication I see three core requirements:
  1) We need everything supported through mTLS. This is already supported
through in bmcweb.      2) We also need all certificates to be rotated.
This might be supported through Redfish OEM extensions.
  3) Finally we need to support revocations lists. AFIAK, there is no
support for this today.

For authorization we would like to support dynamic role configuration. A
reference implementation for this kind of functionality is Role Based
Access Control (RBAC) in envoy
<https://www.envoyproxy.io/docs/envoy/latest/api-v2/config/rbac/v2/rbac.proto>
.

Finally, I'm expecting we will need an out of band mechanism to talk with
hardware root of trust (e.g. OpenTitan https://opentitan.org/).

I'd be interested to hear how this matches up with other organizations'
needs. I imagine supporting this upstream in Redfish would involve some
changes to the spec, and some changes to bmcweb. So I want to gauge
interest in this beefed up security posture.

Thanks,
Richard

[-- Attachment #2: Type: text/html, Size: 1525 bytes --]

Re: Survey for Certificate Management Needs

[Michael Richardson]

Richard Hanley <rhanley@google.com> wrote:
    > 3) Finally we need to
    > support revocations lists. AFIAK, there is no support for this today.

What are the certificates you speak of for?
If you are talking about HTTPs end-point certificates for bmcweb, then there
is nothing to do for CRLs, because CRLs aren't a function of the HTTPS
End-Entity certificate you are worried about.

They are provided by the CA, and it's a problem of the HTTP browser to
validate.

So I don't understand your CRL point.

    > Finally, I'm expecting we will need an out of band mechanism to talk
    > with hardware root of trust (e.g. OpenTitan https://opentitan.org/).

Possibly.

--
]               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: Survey for Certificate Management Needs

[Richard Hanley]

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

On Mon, May 4, 2020 at 2:21 PM Michael Richardson <mcr@sandelman.ca> wrote:

> Richard Hanley <rhanley@google.com> wrote:
>     > 3) Finally we need to
>     > support revocations lists. AFIAK, there is no support for this today.
>
> What are the certificates you speak of for?
> If you are talking about HTTPs end-point certificates for bmcweb, then
> there
> is nothing to do for CRLs, because CRLs aren't a function of the HTTPS
> End-Entity certificate you are worried about.
>
> They are provided by the CA, and it's a problem of the HTTP browser to
> validate.
>
So I don't understand your CRL point.
>
>
I think that CRL becomes more of an issue when communication is
mutually authenticated.  If a client is given a certificate from the CA,
then there should be a way for that client's cert to be revoked on a BMC.


>     > Finally, I'm expecting we will need an out of band mechanism to talk
>     > with hardware root of trust (e.g. OpenTitan https://opentitan.org/).
>
> Possibly.
>
> --
> ]               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: Type: text/html, Size: 2267 bytes --]

Re: Survey for Certificate Management Needs

[Michael Richardson]

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


Richard Hanley <rhanley@google.com> wrote:
    > I think that CRL becomes more of an issue when communication is
    > mutually authenticated.  If a client is given a certificate from the
    > CA, then there should be a way for that client's cert to be revoked on
    > a BMC.

Again, it's the CA that issues the CRL.
If you want to revoke authorization, then you need to do that.
I'm unware of client-certificate based authorization in bmcweb at this time.

If your authorization process if just "signed by CA foo"
(i.e. authentication), then you would have to rely on the CA to revoke the
certificate.

If your authorization process consists of a list of pinned EE certificates,
then you could delete/mark-inactive the broken certificate.

If you combine both methods, then in theory, you could have a "anything
signed by CA foo, unless it is on blacklist X".  But that's not a CRL, that's
a blacklist.

--
]               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: Survey for Certificate Management Needs

[Richard Hanley]

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

On Mon, May 4, 2020 at 5:20 PM Michael Richardson <mcr@sandelman.ca> wrote:

>
> Richard Hanley <rhanley@google.com> wrote:
>     > I think that CRL becomes more of an issue when communication is
>     > mutually authenticated.  If a client is given a certificate from the
>     > CA, then there should be a way for that client's cert to be revoked
> on
>     > a BMC.
>
> Again, it's the CA that issues the CRL.
> If you want to revoke authorization, then you need to do that.
> I'm unware of client-certificate based authorization in bmcweb at this
> time.
>

There is some support for it in bmcweb. Intel added it at the beginning of
the year.  We've just started looking into it, so I don't have a great idea
of what is and isn't implemented yet.


>
> If your authorization process if just "signed by CA foo"
> (i.e. authentication), then you would have to rely on the CA to revoke the
> certificate.
>
> If your authorization process consists of a list of pinned EE certificates,
> then you could delete/mark-inactive the broken certificate.
>
> If you combine both methods, then in theory, you could have a "anything
> signed by CA foo, unless it is on blacklist X".  But that's not a CRL,
> that's
> a blacklist.
>
>
Perhaps I mispoke here, but let's imagine a situation where a machine is
suspected to have been tampered with.  In that case the machine could be
re-imaged and have the CA sign a new cert with the same username.  The CA
would then need to deploy the CRL to any servers (BMCs in this case) that
interacted with that user. In practice (for us at least), that CA doesn't
really know what users are authorized where, so the CRL is widely
distributed.

That's also one of the reasons I like RBAC, and other systems like it. They
do a really good job at cleanly separating authorization and
authentication.

> --
> ]               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: Type: text/html, Size: 3129 bytes --]