Subject: [Anima] Device Certificate Deployment Automation with ACME using BRSKI

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 2 Aug 2019 14:09:29 -0400

All,

During the last IETF meeting in Montreal we had a side meeting to discuss
the
deployment automation of ACME issued certificates to devices, and the
potential
use of the BRSKI mechanism to help with this. It was clear from the
discussion
that BRSKI can be used to help address this use case, and that further
discussion is
needed to define the needed enhancements to BRSKI.

The current BRSKI mechanism only briefly discusses the Cloud Registrar
option in
section 2.7, which could be used to help address this use case.

Michael Richardson and I had another meeting over lunch yesterday to
further
discuss this and we decided to work on a new draft to describe the issue
and
define a solution.

Because of vacations and other commitments, we will try to publish the
first
version of the draft early October.

Regards,
 Rifaat & Michael

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 6 Aug 2019 13:05:24 +0000

Hi guys,

After the meeting and from corridor conversations with Toerless, I had actually already started on such a draft.

What I have started so far is attached. Its not on a public repo yet, but will put it there. You are already named on it Rifaat, happy to add you too Michael and you can help figure out some of the open redirect options outlined in it ☺

My high level thoughts on this were to keep the ACME specifics out of the draft, and use the draft to define the cloud RA behaviour, and the pledge behaviour when interacting with the cloud RA, and the various cert, CA, TLS, redirect, etc. details. The fact that the RA (whether cloud or local) *may* use ACME to talk to the CA is transparent to the pledge.

I was thinking that the ACME specifics could be covered in a different draft based on merging draft-yusef-acme-3rd-party-device-attestation and draft-friel-acme-integrations, but leave the BRSKI clarifications/specifics in this one.

Thoughts?
Owen

From: Iot-onboarding <[email-masked]> On Behalf Of Rifaat Shekh-Yusef
Sent: 02 August 2019 19:09
To: [email-masked]; [email-masked]
Subject: [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI

All,

During the last IETF meeting in Montreal we had a side meeting to discuss the
deployment automation of ACME issued certificates to devices, and the potential
use of the BRSKI mechanism to help with this. It was clear from the discussion
that BRSKI can be used to help address this use case, and that further discussion is
needed to define the needed enhancements to BRSKI.

The current BRSKI mechanism only briefly discusses the Cloud Registrar option in
section 2.7, which could be used to help address this use case.

Michael Richardson and I had another meeting over lunch yesterday to further
discuss this and we decided to work on a new draft to describe the issue and
define a solution.

Because of vacations and other commitments, we will try to publish the first
version of the draft early October.

Regards,
 Rifaat & Michael

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 6 Aug 2019 14:37:41 +0000

FYI, Its up on github now:

https://github.com/upros/brski-cloud

From: Anima <[email-masked]> On Behalf Of Owen Friel (ofriel)
Sent: 06 August 2019 14:05
To: Rifaat Shekh-Yusef <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI

Hi guys,

Thoughts?
Owen

From: Iot-onboarding <[email-masked]<mailto:[email-masked]>> On Behalf Of Rifaat Shekh-Yusef
Sent: 02 August 2019 19:09
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI

All,

Regards,
 Rifaat & Michael

---

From: Kent Watsen <[email-masked]>
Date: Tue, 6 Aug 2019 15:01:18 +0000

Skimming quickly, I see now the direction to go to a cloud registrar to be redirected to a local registrar.  I feel compelled to point out that this is exactly what SZTP (RFC 8572) does, or at least, supports.  Actually, as a more general statement, it was originally said that the two WG's approaches were different, but they are now becoming more and more alike.  Well, since SZTP is published already, it's more like the ANIMA approach is becoming more like SZTP, albeit seemingly with more complexity.

Regarding ACME integration during bootstrap, I think the basic desire is to configure a device to obtain a certificate via ACME, configuration which so happens to be provided at the time of the bootstrap event, but could also happen at anytime thereafter.   Support for such configuration should be added to https://tools.ietf.org/html/draft-ietf-netconf-keystore <https://tools.ietf.org/html/draft-ietf-netconf-keystore>.   

Kent

> On Aug 6, 2019, at 10:37 AM, Owen Friel (ofriel) <[email-masked]> wrote:
> 
> https://github.com/upros/brski-cloud <https://github.com/upros/brski-cloud>
>  
>  
> From: Anima <[email-masked] <mailto:[email-masked]>> On Behalf Of Owen Friel (ofriel)
> To: Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> What I have started so far is attached. Its not on a public repo yet, but will put it there. You are already named on it Rifaat, happy to add you too Michael and you can help figure out some of the open redirect options outlined in it J
>  
> I was thinking that the ACME specifics could be covered in a different draft based on mergingdraft-yusef-acme-3rd-party-device-attestation and draft-friel-acme-integrations, but leave the BRSKI clarifications/specifics in this one.
>  
> Thoughts?
> Owen
>  
>  
>  
>  
> From: Iot-onboarding <[email-masked] <mailto:[email-masked]>> On Behalf Of Rifaat Shekh-Yusef
> To: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> _______________________________________________
> Anima mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/anima <https://www.ietf.org/mailman/listinfo/anima>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Aug 2019 11:52:56 -0400

Kent Watsen <[email-masked]> wrote:
    > Skimming quickly, I see now the direction to go to a cloud registrar to
    > be redirected to a local registrar.  I feel compelled to point out that
    > this is exactly what SZTP (RFC 8572) does, or at least, supports.
    > Actually, as a more general statement, it was originally said that the
    > two WG's approaches were different, but they are now becoming more and
    > more alike.  Well, since SZTP is published already, it's more like the
    > ANIMA approach is becoming more like SZTP, albeit seemingly with more
    > complexity.

Yes, I had hoped to push towards this view.

    > Regarding ACME integration during bootstrap, I think the basic desire
    > is to configure a device to obtain a certificate via ACME,
    > configuration which so happens to be provided at the time of the
    > bootstrap event, but could also happen at anytime thereafter.  Support
    > for such configuration should be added to
    > https://tools.ietf.org/html/draft-ietf-netconf-keystore

agreed.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Aug 2019 00:12:42 +0200

> Skimming quickly, I see now the direction to go to a cloud registrar to be redirected to a local registrar.  I feel compelled to point out that this is exactly what SZTP (RFC 8572) does, or at leas…

I ranted about the need to better describe the common architecture 
already in prior emails to the anima list.

Complexity is in the eye of the beholder.

I like the modularity/flexibility that NetConf provides, but of
try to find someone who understands how to duplicate the full
enrolment process of BRSKI+EST with equivalent NetConf
supported Yang object models (especially for TA and Cert enrollment).
And then find more constrained devices that would more happily 
go with that more (IMHO) flexible model. 

But given how constrained devices also do not like TLS of
BRSKI, it would be great if we could come up with a single
preferred transport to use with either server-controlle workflow
(like SZTP/Netconf) and  client-side controlled (like BRSKI).

> Regarding ACME integration during bootstrap, I think the basic desire is to configure a device to obtain a certificate via ACME, configuration which so happens to be provided at the time of the boo…

I think what you say is not specific to ACME but true for any RA<->CA protocol.

The fact that NetConf/SZTP allows to enrol the certificate any time later
is a key difference. I think architecturally, you want to make it as
soon as possible, but for example you may still want to first do
some additional attestation before the key enrollment. This is where
BRSKI+EST is a lot less flexible in design, but given how i think
there is no model for attestation in IETF, its hard t make the point now.

The only ACME specific thing i can think of are the mechanisms for the
RA to prove to the CA posession of a domain-name/prefix. That i think
is independent of the key-store. More related to the ability of the
RA to create DNS entries. No idea if there is a yang model for that
(would be nice).

Cheers
    Toerless

---

From: Kent Watsen <[email-masked]>
Date: Wed, 7 Aug 2019 00:09:38 +0000

Hi Toerless,

> already in prior emails to the anima list.

Good.  

> Complexity is in the eye of the beholder.

True, but it seems that getting a domain certificate and getting an initial configuration are at least two distinct steps in ANIMA, whereas they're rolled into one step with SZTP.   

While the comparison may not apply perfectly, for a long time in filesystems, the redundancy layer (e.g., RAID-6) and the volume management layer were distinct, but ZFS collapsed them into one layer, for the better.  I wonder if we might not have something like that here...

> go with that more (IMHO) flexible model. 

That paragraph didn't parse completely for me, but I get the sense that there is an incomplete view, in both directions, for how things work.   Ideally, I would be more active in ANIMA but, I've been so busy that I haven't had time.   Perhaps we could schedule a call to go over where/how SZTP can fit into the ANIMA model?

> (like SZTP/Netconf) and  client-side controlled (like BRSKI).

Regarding TLS, SZTP depends on TLS in a soft way, other bindings could be defined if needed.

Regarding which side controls the flow, I'm unsure if SZTP is server-controlled, at least, it is the device the initiates the connection to the server, but perhaps you mean what I'd refer to a post-bootstrapping steps that are needed to complete the full bringup.

> I think what you say is not specific to ACME but true for any RA<->CA protocol.

Yes.

> there is no model for attestation in IETF, its hard t make the point now.

I'm quasi-working with Henk on RATS...

> RA to create DNS entries. No idea if there is a yang model for that

The keystore relation here is threefold:

  1) when shipped from manufacturing, the keystore may be pre-populated
      with the device's, e.g., TPM-protected asymmetric key and associated
      IDevID certificate.

  2) when deployed, an alternate LDevID certificate may be configured in
      the keystore.

  3) ACME or equivalent could be used to auto-update certificates as
      needed (the keystore model doesn't support this yet)

I'm not aware of a YANG model to configure a DNS server as of yet.

Kent

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Aug 2019 17:22:24 -0400

> ANIMA approach is becoming more like SZTP, albeit seemingly with more

SZTP does not directly result in the same mutually authenticated TLS (EST)
connection to a Registrar that BRSKI does.  This was not an explicit SZTP goal.

What it could do though, is to provide a source of (secure) bootstrap
configuration in which such a connection could be initiated.  In my mind,
I see a fragment of signed JUNOS, IOS (CISCO, not Apple), etc. CLI
configuration that initiates the connection. Such a thing would not be
standardized.
But, I would think that this is exactly the kind of thing that could
be encoded in YANG.

My understanding of https://tools.ietf.org/html/draft-ietf-netconf-keystore
is that it would provided for Registrar initiated (PUSH) updating of device
certificates, but would not provide a way for a device to initiate (PULL) to
a securely identified EST server.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Aug 2019 17:24:38 -0400

Kent Watsen <[email-masked]> wrote:
    > True, but it seems that getting a domain certificate and getting an
    > initial configuration are at least two distinct steps in ANIMA, whereas
    > they're rolled into one step with SZTP.

I'm missing where SZTP gets a domain certificate in a standard way.

I totally see how it gets initial configuration though.
I also see how that initial configuration can be caused to do an enrollment,
by leveraging some specific, vendor-specific, configuration command.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 8 Aug 2019 16:05:55 +0000

Hi Michael,

> connection to a Registrar that BRSKI does.  This was not an explicit SZTP goal.

It's true that EST isn't used, but there is a mutually-authenticated TLS connection to the SZTP bootstrap server, which is effectively the same as BRSKI's Registrar.   

> But, I would think that this is exactly the kind of thing that could

Indeed, this what RFC 8572 describes (in section 5.6 and also in C.3, item #3) and the primary motivation behind https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server <https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server> and https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server <https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server>.

> a securely identified EST server.

Sounds correct, but clarifying:

1) the current keystore model is all about enabling a controller/NMS application to configure/set/push keys and associated end-entity certificates to a device.

2) there is a suggestion that the keystore model could/should be extended to support ACME (or similar), in which case one might claim that the device had "pulled" an end-entity certificate from a "securely identified server" (dropping the "EST" part).

3) the truststore model (draft-ietf-netconf-trust-anchors) can be used by a controller/NMS application to configure/set/push trust-anchor certs used, e.g., to verify a remote server's end-entity certificate.

Cheers,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Thu, 8 Aug 2019 17:02:05 +0000

> by leveraging some specific, vendor-specific, configuration command.

I think your understanding is complete.  

There isn't a single "domain certificate".   Instead, there are:

1) certificates pledges use during bootstrap process, which may be: a) used to authenticate bootstrap servers.  These certificates are learned via SZTP "redirect information" or b) used to authenticate owner-certificates.  These certificates are learned via the ownership voucher (RFC 8366).

2) certificates pledges use to authenticate subsequent (e.g., management) connections.  These certificates may be configured, e.g., via the keystore and truststore models over NETCONF, RESTCONF, or COAP.

So, rather than a single certificate or a single protocol, there's a collection of each, yet all defined (once all is published) via standards (not vendor-specific, configuration commands).

Makes sense?

Kent

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Aug 2019 16:50:43 -0400

> It's true that EST isn't used, but there is a mutually-authenticated
    > TLS connection to the SZTP bootstrap server, which is effectively the
    > same as BRSKI's Registrar.

It's not clear to me that this always occurs in the USB or DHCP cases :-)

    > Indeed, this what RFC 8572 describes (in section 5.6 and also in C.3,
    > item #3) and the primary motivation behind
    > https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server
    > <https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server>
    > and
    > https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server
    > <https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server>.

Got it.

    > 1) the current keystore model is all about enabling a controller/NMS
    > application to configure/set/push keys and associated end-entity
    > certificates to a device.

    > 2) there is a suggestion that the keystore model could/should be
    > extended to support ACME (or similar), in which case one might claim
    > that the device had "pulled" an end-entity certificate from a "securely
    > identified server" (dropping the "EST" part).

    > 3) the truststore model (draft-ietf-netconf-trust-anchors) can be used
    > by a controller/NMS application to configure/set/push trust-anchor
    > certs used, e.g., to verify a remote server's end-entity certificate.

But, more interestingly, it can be used to update the trust anchors, to
enable a resale/transfer of ownership!

---

From: Kent Watsen <[email-masked]>
Date: Thu, 8 Aug 2019 21:26:37 +0000

> It's not clear to me that this always occurs in the USB or DHCP cases :-)

To your smiley-face, the ultimate USB use-case entails using no network at all, so you're right that there is no mutually-authenticated TLS connection then!

For all other cases, it's actually possible that the bootstrapping event may lead to a mutually-authenticated TLS connection.  It entails the device consuming "signed data", which means it needs also an "ownership voucher" as well as an "owner certificate".   [note: terms in "quotes" are defined in RFC 8572]

> enable a resale/transfer of ownership!

I think I see a smiley-face here too  ;)

But, seriously, no.  It's expected that decommissioning will returned a device back to its factory default state.  No manufacturer will agree that it is anything other than the state of the device when it was manufactured.   Anything other than that could be leveraged to mount an attack.  Change in ownership-assignment needs to occur through some other means, of which there are many but, in the end, if the 2nd-owner cares about the security (not just the convenience) of bootstrapping, then they are strongly advised to purchase never before used equipment.

Kent

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Aug 2019 11:16:24 -0400

> I think I see a smiley-face here too  ;)

Sadly, no.

    > But, seriously, no.  It's expected that decommissioning will returned a
    > device back to its factory default state.  No manufacturer will agree
    > that it is anything other than the state of the device when it was
    > manufactured.   Anything other than that could be leveraged to mount an
    > attack.  Change in ownership-assignment needs to occur through some
    > other means, of which there are many but, in the end, if the 2nd-owner
    > cares about the security (not just the convenience) of bootstrapping,
    > then they are strongly advised to purchase never before used
    > equipment.

This is indeed the tussle the BRSKI document has been dealing with
in its IESG review.  If we can't change the trust anchors used to verify
the voucher, then how can the device be onboarded after the MASA
has gone away?

I don't understand how RFC8572 slipped through the IESG without resolving this.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 9 Aug 2019 16:16:51 +0000

> On Aug 9, 2019, at 11:16 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

Oh, wait, my prior response wasn't wholly accurate.

The factory default state reflects zero remnants, but it doesn't necessarily mean the same OS-version as the day the device left the factory.   Many devices don't have enough NV storage to keep the original OS forever, not to mention that it would be rather silly as, better, would be to keep what's considered the last known-good OS image (which may not be the same thing).   Many devices will effectively overwrite the previous OS image ("don't touch the power button during install!") and thus what happens when pressing the "reset to factory default" button is a reflection of what "factory default" means to the new OS image.   The good news is that new OS images can contain new CA certificates, for authenticating well-known services (e.g., MASA, OVIS, etc.).  What cannot change is the IDevID certificate (LDevIDs are wiped).

Of course, all this assumes the manufacturer is still around to release OS updates, but this is simply part of the business decision that customers need to consider when purchasing equipment.   The probability of a successful bootstrap shortly after fresh purchase directly from the manufacturer is very high, but lowers over time as risks around businesses going belly-up start to creep in.  A device sitting on a shelf for a decade, or devices bought on eBay, may not bootstrap without an OS upgrade.

None of the above reflects how to support change in ownership, though.   A device reset to factory default has no "owner", just some trust anchors that can be used to verify an entity claiming to be its owner.  What backend sale-channel integration or customer-handoff protocol might be used to support change in ownership is out of scope.

> I don't understand how RFC8572 slipped through the IESG without resolving this.

Perhaps because BRSKI leads with ephemeral vouchers and hence the need for online MASAs (with offline support tacked on the side), whereas SZTP leads with optional use of vouchers but, when used, they're mostly non-ephemeral and accessible at time or purchase (with ephemeral voucher support tacked on the side).   The shift in emphasis begs the question, so they're asking it.  Still, it seems more like a customer/business issue than something IESG should worry about.

Kent