Subject: [Iot-onboarding] ACME integrations with BRSKI and the cmcRA EKU

From: Michael Richardson <[email-masked]>
Date: Fri, 04 Dec 2020 15:33:06 -0500

Please excuse the long intro.
Due to the cross-post, I want to make sure that everyone has the right context.

draft-ietf-acme-integrations proposes some best practices on how to use an
ACME certification authority like LetsEncrypt with an onboarding protocol
like BRSKI (draft-ietf-anima-bootstrapping-keyinfra)

BRSKI is based upon RFC7030 -- Enrollment over Secure Transport.
(One of three methods the IETF has, including CMP and now SCEP)
A "burden" of using BRSKI is that there are two (possibly private) PKIs: one
run my the manufacturer, and one run by (or for) the owner.
{ draft-richardson-t2trg-idevid-considerations and
draft-richardson-anima-masa-considerations is about the manufacturer PKI }

BRSKI is essentially the authorized replacement of a device's manufacturer
identity with a local identity.   This protocol (and others like it) are
critical to having true ownership of devices.

The ACME integration document lightens some of the burden of having the
operator run PKI in smaller environments.
It does not remove the necessicity of having some kind of "home base" which
will manage the enrollment.  The converged 6tisch/BRSKI term for this is JRC,
R being for Registrar.

RFC7030 defines the cmcRA EKU.  The Registrar's EE certificate is supposed to
have this bit set.  This is an indication that the Certification Authority
has effectively authorized that Registrar as legitimate.
If not for this bit, then a peer in the same CA could claim to be a
Registrar, and then could (re-)enroll entities into a different CA.

For the Autonomic Control Plane (ACP/ANIMA) use of BRSKI, this would be a
problem, and draft-ietf-anima-autonomic-control-plane section 6.2.5 discusses
this.   The ACP determines where the edges of the domain are by looking for
nodes that share the same CA.  Homenet participants will remember that
determining the perimiter of the (home) domain was a problem.

Now, if a "public" CA is used via ACME, such as LetsEncrypt, then the
edge-of-domain checks become meaningless.
This is likely not a problem for many of the IoT uses of BRSKI that would
benefit from draft-ietf-acme-integrations, as they don't need/want to form an
ACP.

A Registrar that uses RFC8555 to talk to it's CA could have three different
kinds of anchors:
1) it could use an RFC8555/ACME EE certificate that it obtained for itself.
   In that case, the cmcRA bit is most likely not set.

2) it could have a self-signed EE certificate, where the cmcRA bit could in
   fact be set. {Would it have any real meaning?}

3) it could use a raw-public-key.

The RFC8366 voucher system can cope with of these three things.
BRSKI does not require that the Registrar have a publically validatable EE certificate.
(nor does it forbid it)
Note that MASA can in fact evaluate these things!
The question whether there might be some rules that I haven't thought about.

One thing that occurs to me that a pledge which *can* form an ACP, probably
should *not* if the cmcRA bit is not set.  Or perhaps, the MASA should do
this evaluation, and should a TBD attribute in the voucher.

One thought that I had was whether ACME/8555 uses like envisioned in
draft-friel-acme-subdomains-03 could/should allow the entity requesting
authorization for a subdomain to request an EE certificate for the apex of
that zone with some bit set.  Would some kind of qualified cmcRA EKU make sense?

ofriel> Is this pretty much true for both self-signed and private-CA signed
ofriel> registrar certs? The pinned-domain-cert in the voucher could be EE or
ofriel> CA cert, and in either case it’s the MASA that tells the pledge to
ofriel> trust it. As long as the cert (EE or CA) is added to the trust store
ofriel> of the pledge, you would need different pledge logic to check '(if RA
ofriel> cert == self-signed then ignore cmcRA) else (if RA cert == EE cert
ofriel> then check cmcRA) which seems clunky.

ofriel> And as I believe you cannot get cmcRA from a public CA today, we
ofriel> don’t even have the halfway house of getting the RA EE cert manually
ofriel> from a public CA with the cmcRA EKU set, but automating the bluk
ofriel> pledge certs via ACME.

ofriel> Seems like mixing two sort of orthogonal things - subdomains and cmcRA..

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Esko Dijk <[email-masked]>
Date: Mon, 7 Dec 2020 13:53:37 +0000

Thanks for the useful intro Michael. 

> A Registrar that uses RFC8555 to talk to it's CA could have three different

The Registrar also could have different identities used at the same time:

1) ACME client TLS identity   (towards ACME server)
2) Registrar/EST-server TLS server identity  (towards Pledges)
3) Registrar/EST-server signing identity  (for signing Voucher Requests)
4) Registrar TLS client identity towards MASA server

For #1, ACME client it could use any identity / 'account' that was able to prove control of the DNS domain, so it can be unrelated to other identities. 

> 3) it could use a raw-public-key.

These options could be considered for the signing identity #3:

1) it wouldn't work if the 'RA' flag is not set. The BRSKI security architecture depends on 'RA' being set for Registrars, and also ACP does. In my view a MASA MUST check for 'RA'.
2) this can work
3) Registrar signs with a certificate not with a raw-public-key. And a raw-public-key cannot have an 'RA' flag set. So that wouldn't work

Option 2) looks good as an identity for signing Voucher Requests.  Either a single selfsigned RA+CA cert, or a chain of two: RA -> self-signed-CA. The latter is useful as it allows in the future more Registrars (with RA flag set)
to be created within the same private domain (CA).  Of course this certificate / chain must then be created by hand i.e. it cannot be automated using ACME.  Do you see this as a problem? To me it seems acceptable.

Details of this solution: MASA will accept the above signing (since 'RA' is set - check passes) and will pin one of these certs. The Pledge will too accept as per BRSKI 5.6.2 because the Registrar's cert is either equal to, or chains to, the pinned-domain-cert.
The Pledge will do after BRSKI-specific bootstrap operations the GET /cacerts (Section 5.9.1) and the Registrar then serves back 2 CAs: { self-signed CA ,  ACME CA } .  The Pledge will then do EST e.g. /simpleenroll with Registrar; and Registrar 
meanwhile interfaces as a client with the ACME server to obtain  a new operational domain cert for the Pledge under the DNS domain owned by the Registrar. The Pledge can verify this new cert against its trust store that now contains the 
two CAs: { self-signed CA ,  ACME CA } , so it will validate.  Note that the Registrar enrolls the Pledge into a domain (with ACME-issued cert) that the MASA knows nothing about!  I assume this is allowed by BRSKI as I read that the Pledge is
supposed to install the /cacerts response in its trust store. 

Now if above solution option 2) works with ACME, there seems to be no need to request certs with 'RA' set from the ACME CA.  The 'RA' certs are under the control of the Registrar's private domain. The auto-created EE certs are created
by the ACME CA under control of Registrar.  

Or would there still be some need to use option 1) and update the ACME RFC to enable ACME CA handing out certs with cmcRA set?

> should *not* if the cmcRA bit is not set.  

As said above the BRSKI security architecture depends on 'RA' being set for Registrars, and also ACP does. So it seems risky to assume situations in which it is not set and MASA lets the bootstrap continue.
So the Pledge doesn't need to evaluate if cmcRA is present - because the bootstrap wouldn't succeed in the first place if cmcRA is absent, right? Or do I miss something.

Best regards
Esko

IoTconsultancy.nl  |  Email/Teams: [email-masked] 

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of Michael Richardson
Sent: Friday, December 4, 2020 21:33
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: Max Pritikin (pritikin) <[email-masked]>
Subject: [Anima] ACME integrations with BRSKI and the cmcRA EKU

---

From: Deb Cooley <[email-masked]>
Date: Mon, 21 Dec 2020 05:54:23 -0500

I don't post often, so go easy. And I've not read up on the current state
of BRSKI or MASA.  This response is based only on the original post.

If you are looking for some sort of trust for an identity, then option 2 -
the self signed cert w/ cmcRA bit set - is not it (as you allude to in your
parenthetical).  It is in the same category as a random certificate w/out
the cmcRA bit (from your background).

Option 3 is similarly flawed.  raw public keys have no identity (obviously)
and rely on knowledge of which ID goes with it via some sort of out of band
mechanism.

Now, I don't know how happy I would be to see cmcRA be an option in an auto
issued certificate (i.e. via ACME).  I'm not sure how that would work.  We
need to know the entity holding the key/certificate is actually supposed to
have it.

These are hard problems, for sure.

Deb Cooley
NSA
for real work address:  [email-masked]

On Mon, Dec 7, 2020 at 8:54 AM Esko Dijk <[email-masked]>
wrote:

> For #1, ACME client it could use any identity / 'account' that was able to
> prove control of the DNS domain, so it can be unrelated to other
> identities.
>
> 1) it wouldn't work if the 'RA' flag is not set. The BRSKI security
> architecture depends on 'RA' being set for Registrars, and also ACP does.
> In my view a MASA MUST check for 'RA'.
> 2) this can work
> 3) Registrar signs with a certificate not with a raw-public-key. And a
> raw-public-key cannot have an 'RA' flag set. So that wouldn't work
>
> Option 2) looks good as an identity for signing Voucher Requests.  Either
> a single selfsigned RA+CA cert, or a chain of two: RA -> self-signed-CA.
> The latter is useful as it allows in the future more Registrars (with RA
> flag set)
> to be created within the same private domain (CA).  Of course this
> certificate / chain must then be created by hand i.e. it cannot be
> automated using ACME.  Do you see this as a problem? To me it seems
> acceptable.
>
> Details of this solution: MASA will accept the above signing (since 'RA'
> is set - check passes) and will pin one of these certs. The Pledge will too
> accept as per BRSKI 5.6.2 because the Registrar's cert is either equal to,
> or chains to, the pinned-domain-cert.
> The Pledge will do after BRSKI-specific bootstrap operations the GET
> /cacerts (Section 5.9.1) and the Registrar then serves back 2 CAs: {
> self-signed CA ,  ACME CA } .  The Pledge will then do EST e.g.
> /simpleenroll with Registrar; and Registrar
> meanwhile interfaces as a client with the ACME server to obtain  a new
> operational domain cert for the Pledge under the DNS domain owned by the
> Registrar. The Pledge can verify this new cert against its trust store that
> now contains the
> two CAs: { self-signed CA ,  ACME CA } , so it will validate.  Note that
> the Registrar enrolls the Pledge into a domain (with ACME-issued cert) that
> the MASA knows nothing about!  I assume this is allowed by BRSKI as I read
> that the Pledge is
> Now if above solution option 2) works with ACME, there seems to be no need
> to request certs with 'RA' set from the ACME CA.  The 'RA' certs are under
> the control of the Registrar's private domain. The auto-created EE certs
> are created
> Or would there still be some need to use option 1) and update the ACME RFC
> to enable ACME CA handing out certs with cmcRA set?
>
> As said above the BRSKI security architecture depends on 'RA' being set
> for Registrars, and also ACP does. So it seems risky to assume situations
> in which it is not set and MASA lets the bootstrap continue.
> So the Pledge doesn't need to evaluate if cmcRA is present - because the
> bootstrap wouldn't succeed in the first place if cmcRA is absent, right? Or
> do I miss something.
>
> Best regards
> Esko
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>