Subject: [Anima] BRSKI support for asynchronous processing

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 23 Nov 2018 16:53:45 +0000

Hi everyone,

We are currently in the process of discussing different scenarios and approaches for the onboarding of (IoT) devices in plants, substations, or cloud-based services. The current BRSKI document provides here a good approach to address the case in which a pledge has an online connection to a domain registrar to request a voucher for enrolling in a target domain including the enrollment at the PKI. For the enrollment there exists the binding between the certification request (as PKCS#10 object) and the communication connection. I would see this as synchronous approach, as the interaction between the pledge and the domain registrar and also the PKI (CA) is based on a "live" communication connection.

Besides this, we see further use cases, in which the connection to the PKI is not always available. This may be the case if the connection to the CA is only temporary available or not directly available. Here, the approach would require a rather asynchronous handling. In such a setup the domain registrar could for instance store the object (certification request) and forward it upon connectivity to the PKI for further processing. The forward may be based on a communication connection or even manually. This asynchronous approach requires that the object itself is self-protecting ensuring its integrity (like a PKCS#7 wrapping of the PKCS#10 request or similar). Based on the specified BRSKI features, we did not see the support for this type of requirements directly.

Before starting a discussion about potential solution approaches, I would like to get some sense, if this use case is also considered as target scenario for BRSKI. If yes, are there already ideas on how to address asynchronous objects? We already had some discussion in our group about potential approaches to handle such an requirement and I think it could be an interesting enhancement of a domain registrar to support both use cases, synchronous and asynchronous object processing. Since the domain registrar should be less restricted than the onboarding devices, the devices could have an option which approach to choose.
Any thought on this?

Best regards
Steffen

--
Steffen Fries
Siemens AG, Corporate Technology

---

From: Eliot Lear <[email-masked]>
Date: Fri, 23 Nov 2018 18:56:12 +0100

Hi Steffen

> On 23 Nov 2018, at 17:53, Fries, Steffen <[email-masked]> wrote:
> 
> Hi everyone,
> 
> We are currently in the process of discussing different scenarios and approaches for the onboarding of (IoT) devices in plants, substations, or cloud-based services. The current BRSKI document provides here a good approach to address the case in which a pledge has an online connection to a domain registrar to request a voucher for enrolling in a target domain including the enrollment at the PKI. For the enrollment there exists the binding between the certification request (as PKCS#10 object) and the communication connection. I would see this as synchronous approach, as the interaction between the pledge and the domain registrar and also the PKI (CA) is based on a “live” communication connection.

I think the way to put this is that the Registrar is assumed to be integral/co-resident with the CA.

> Besides this, we see further use cases, in which the connection to the PKI is not always available. This may be the case if the connection to the CA is only temporary available or not directly avai…

To be clear, are we concerned about the EST request or the BRSKI request?  The CA need not be available for BRSKI, but it does need to be available for EST.

Eliot

---

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 23 Nov 2018 19:27:03 +0000

Hi Eliot

I assumed it to be collocates with the RA and that the CA is separate.

I should have been more specific. I was referring to the EST request.  The BRSKI request regarding the voucher is assumed to a proxy residing inside the plant. I assumed a strong binding of EST and BRSKI.

Steffen

---

From: Eliot Lear <[email-masked]>
Date: Sun, 25 Nov 2018 14:09:34 +0100

Hi Steffen

> On 23 Nov 2018, at 20:27, Fries, Steffen <[email-masked]> wrote:
> 
> Hi Eliot
> 

Ok, well there we have it ;-)

> I should have been more specific. I was referring to the EST request.  The BRSKI request regarding the voucher is assumed to a proxy residing inside the plant. I assumed a strong binding of EST and…

Right.  And so with this, I think we do indeed have some questions:

Does the registrar have to play the role of “store and forward” and retain state or is it better to say, “Call me back another time”?
If we do want the registrar to retain state, then intermediate states need to be defined in EST, and perhaps in other mechanisms as well, to say, “Do you have my credential now?”
If we are assuming that the registrar and the CA are not co-resident, then there is a question of protecting the credential, as you mention.  Should that credential returned be encrypted?

And so the real question, to me, is whether or not we are handling the case where one has something of a roaming CA, where it is only present on occasion, or has to handle (re)enrolments periodically.

Right?

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Nov 2018 08:21:55 +1300

> And so the real question, to me, is whether or not we are handling the case where one has something of a roaming CA, where it is only present on occasion, or has to handle (re)enrolments periodical…

Coud you (both of you, because the answers might be different) give a concrete
description of the real-world scenarios you are thinking about? Because to
me, it isn't clear where these requirements are coming from.

In particular, are they part of autonomic networking, or do they fit
elsewhere?

    Brian

    Brian

---

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 26 Nov 2018 11:13:56 +0000

Hi Eliot

Right.  And so with this, I think we do indeed have some questions:
·         Does the registrar have to play the role of “store and forward” and retain state or is it better to say, “Call me back another time”?
[stf] yes, store and forward would be what I have in mind.
·         If we do want the registrar to retain state, then intermediate states need to be defined in EST, and perhaps in other mechanisms as well, to say, “Do you have my credential now?”
[stf] This would be one way of doing it, although I’m not sure about the state enhancement as EST utilizes the binding to the TLS connection in the PKCS#10 request. And for an asynchronous operation, a self-containing container allowing a local (protected) storage may be better. This depends on the security of the domain registrar. There are further enrollment protocols, which feature this property. But from your answer before I gathered, that there is a 1:1 binding between BRSKI and EST. Technically, it should also be possible to also utilize alternative enrollment protocols.
·         If we are assuming that the registrar and the CA are not co-resident, then there is a question of protecting the credential, as you mention.  Should that credential returned be encrypted?
[stf] Probably not in every case. I would hope that each enrolling device is generating its key pair locally and only performs the certification request/response with the target PKI. But I’m sure there are also scenarios, in which also centrally generated keys is favored (e.g., if there is not sufficient entropy on the enrolling device). In the latter case encryption would be required.
And so the real question, to me, is whether or not we are handling the case where one has something of a roaming CA, where it is only present on occasion, or has to handle (re)enrolments periodically.
[stf] Re-enrollment is an interesting question, but I think it could be handled in a similar way as the initial enrollment, assumed, it is initiated before the window of CA connectivity.

Steffen
Right?

Eliot

---

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 26 Nov 2018 11:36:00 +0000

Hi Brian 

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Sonntag, 25. November 2018 20:22
To: Eliot Lear <[email-masked]>; Fries, Steffen (CT RDA ITS) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Anima] BRSKI support for asynchronous processing

> And so the real question, to me, is whether or not we are handling the case where one has something of a roaming CA, where it is only present on occasion, or has to handle (re)enrolments periodical…

Coud you (both of you, because the answers might be different) give a concrete description of the real-world scenarios you are thinking about? Because to me, it isn't clear where these requirements are coming from.
[stf] The scenario I had in mind for raising the question was an enrolling device in a plant / building / train wagon, which utilizes already an internal communication network but is not (always) connected with external networks, to which a CA (or also a MASA) is connected. This network already features a domain registrar and my assumption was that the voucher is provisioned to the domain registrar (as self-contained object in a nonce less voucher) not necessarily at the same time the pledge is connecting. This type of scenario results in what I called asynchronous communication. The domain registrar could basically service as a kind of store and forward device towards the external network.  As the voucher is defined a self-containing object, I was looking for something similar for the certification request. In EST PKCS#10 is generated based on the key material for the LDevID. The binding to the pledge's IDevID is done using the TLS connection. This is not a problem in the synchronous case, in which there is an online connection to the CA.  In the asynchronous case, the binding to the IDevID should be done in another way.  

In particular, are they part of autonomic networking, or do they fit elsewhere?
[stf] I would consider this as part of autonomic networking with the restriction, that the network may not be connected to all services at the same time. 

Steffen

    Brian

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Nov 2018 08:37:17 +1300

> [stf] The scenario I had in mind for raising the question was an enrolling device in a plant / building / train wagon, which utilizes already an internal communication network but is not (always) c…

OK, thanks. I'm interested in another scenario too: one where the operator will not accept using a connection to the open Internet and therefore will not accept any real-time access to any MASA. As I've said for several years, this is a highly likely scenario in some types of network which insist on air-gap security or for some other reason do not trust a MASA (see Randy Bush's comments a few weeks ago, e.g. https://mailarchive.ietf.org/arch/msg/anima/rK_rlT3JH0AFGlS47XSRqQB2DJI ).

For such networks the only solution I can see is that all MASAs are replaced by a single OASA (Operator Authorized Signing Authority) that is configured and controlled by the operator. It handles the Registrar-MASA protocol and returns vouchers exactly like a MASA, except that it emphatically isn't on the global Internet. The OASA would procure a long-life voucher (normally from the relevant MASA, via a nonceless registrar voucher-request) when a device is purchased and added to inventory, and then deliver that voucher or a short-term voucher when a registrar needs it. Instead of using the MASA URL for each manufacturer, registrar-to-OASA connections all use a locally defined URL for the OASA. Otherwise the protocol is standard BRSKI.

Any thoughts?

    Brian

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 Nov 2018 10:04:23 +0000

> For such networks the only solution I can see is that all MASAs are replaced by a single OASA (Operator Authorized Signing Authority) that is configured and controlled by the operator. It handles t…

Yes, several.

First, there is now a mailing list that is related to this, [email-masked] <mailto:[email-masked]>.  This is a follow-up to the side meeting that took place at the IETF where we are at least documenting existing mechanisms and requirements.    There is a GitHub repo https://github.com/iot-onboarding <https://github.com/iot-onboarding> that people can commit into.  We haven’t yet started the requirements aspect, except in as much as we are asking “How"

Second, I agree that there is a desire to handle the case where onboarding doesn’t go all the way out the door to the vendor.  I think that is one use case, and a separate use case is where onboarding does.  To me this boils down to a combination of Join Registrar functionality and a means to communicate proof of possession / proof of ownership to the device through that registrar.  Let’s not create new entities if we can at all avoid doing so.

Eliot

---

From: "Fries, Steffen" <[email-masked]>
Date: Tue, 27 Nov 2018 11:49:30 +0000

Hi Eliot

Any thoughts?

Yes, several.

First, there is now a mailing list that is related to this, [email-masked]<mailto:[email-masked]>.  This is a follow-up to the side meeting that took place at the IETF where we are at least documenting existing mechanisms and requirements.    There is a GitHub repo https://github.com/iot-onboarding that people can commit into.  We haven’t yet started the requirements aspect, except in as much as we are asking “How"
[stf] Thank you for pointing that out. I already subscribed to the list. I completely agree, discussing the requirements is crucial. That was the reason I asked for the support of asynchronous handling.

Second, I agree that there is a desire to handle the case where onboarding doesn’t go all the way out the door to the vendor.  I think that is one use case, and a separate use case is where onboarding does.  To me this boils down to a combination of Join Registrar functionality and a means to communicate proof of possession / proof of ownership to the device through that registrar.  Let’s not create new entities if we can at all avoid doing so.
[stf] Agreed. Although I’m not sure if store and forward could be solely a functionality of the domain registrar and not necessarily a new component.
Getting back to my original question, do you see the asynchronous handling of pledge enrolment as part of the current charter of the working group? If yes, would you rather expect to see EST enhanced to handle asynchronous support or would it be better to allow for alternative enrolment protocol support on the domain registrar featuring the handling of self-contained objects? As the domain registrar is likely to be not a constraint device as a pledge, this choice could technically be provided, while the pledge has the freedom to choose, which enrolment to use.

Steffen

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 Nov 2018 13:11:31 +0000

Hi Steffen

> On 27 Nov 2018, at 11:49, Fries, Steffen <[email-masked]> wrote:
> 
> Getting back to my original question, do you see the asynchronous handling of pledge enrolment as part of the current charter of the working group?

I don’t know (I'll leave the to the chairs).  Assuming yes:

> If yes, would you rather expect to see EST enhanced to handle asynchronous support or would it be better to allow for alternative enrolment protocol support on the domain registrar featuring the handling of self-contained objects? As the domain registrar is likely to be not a constraint device as a pledge, this choice could technically be provided, while the pledge has the freedom to choose, which enrolment to use.

If the domain registrar is not there, that’s an easy one, right?  Device just has to retry until the registrar is present (assuming it’s trying to onboard).  Do you have requirements for more than that?

If the domain registrar is there and the CA is not there, there are seemingly two choices:
Store and forward from the registrar; or
Reject the request until the CA is present

If we add a 3rd approach of forwarding to some intermediary component, then *it* has to store and forward.  In any case, the registrar needs to return a status to the pledge, saying, “Thanks for checking in… check back with me in X minutes” (where X might be some value that can back off based on load.  Another alternative would be to refer to some 3rd player.

To implement the store and forward, the registrar just needs a queue, but the pledge needs to remember the request (and any associated nonce).  And I think that works out because any such behaviour would demand a few new EST RESTful endpoints.

Eliot

---

From: "Fries, Steffen" <[email-masked]>
Date: Tue, 27 Nov 2018 14:02:24 +0000

Hi Eliot
On 27 Nov 2018, at 11:49, Fries, Steffen <[email-masked]<mailto:[email-masked]>> wrote:

[stf] okay :-)

  *   Store and forward from the registrar; or
  *   Reject the request until the CA is present
[stf] yes, I would favor the first one.
If we add a 3rd approach of forwarding to some intermediary component, then *it* has to store and forward.  In any case, the registrar needs to return a status to the pledge, saying, “Thanks for checking in… check back with me in X minutes” (where X might be some value that can back off based on load.
[stf] I think the registrar could do the store and forward. The registrar may even be co-located a local RA.
Another alternative would be to refer to some 3rd player.
[stf] yes, but this would need to be provided by the registrar as URI in some return message.

To implement the store and forward, the registrar just needs a queue, but the pledge needs to remember the request (and any associated nonce).
[stf] yes, this could be probably be handled by the state machine of the enrollment protocol.

And I think that works out because any such behaviour would demand a few new EST RESTful endpoints.
[stf] Hm. That would pose some requirements on the storage of the certification requests on the registrar, as EST protects the transport not necessarily the “rest”. This is where I referred to self-contained. If the registrar would support further enrollment protocols like CMP or SCEP it could easily store the request, until the RA or PKI becomes available.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Nov 2018 08:37:52 +1300

Hi Eliot,
> First, there is now a mailing list that is related to this, [email-masked] <mailto:[email-masked]>.  This is a follow-up to the side meeting that took place at the IETF where we are at least docume…

I'm aware of that list and catching up with is on my to-do list. However, my
immediate concern is specifically ANIMA business - an autonomic network
(the chartered scope for BRSKI). If the solution can be generalised, so
much the better.

> Second, I agree that there is a desire to handle the case where onboarding doesn’t go all the way out the door to the vendor.  I think that is one use case, and a separate use case is where onboard…

Indeed not. My suggestion creates no new protocol and doesn't change anything
for the registrar, proxy, and pledge. It recycles the registrar-MASA protocol
as the registrar-OASA protocol. And presumably it also recycles the registrar-MASA
protocol as the OASA-MASA protocol, when the OASA needs to get a new nonceless
voucher for a newly purchased pledge. I think there's a very modest amount
of "new".

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Nov 2018 08:46:43 +1300

> Hi Eliot
...

> [stf] Thank you for pointing that out. I already subscribed to the list. I completely agree, discussing the requirements is crucial. That was the reason I asked for the support of asynchronous hand…

Again, in the ANIMA context, the air-gap scenario has been discussed
since a very early stage.

> Getting back to my original question, do you see the asynchronous handling of pledge enrolment as part of the current charter of the working group? If yes, would you rather expect to see EST enhanc…

I don't see any reason why the pledge-proxy-registrar chain would change
in any way. It's only obtaining the voucher that needs to be asynchronous,
to avoid the need for real-time communication with the MASA.

And I'm not a WG chair, but I see nothing in the ANIMA charter that would
make this out of scope.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Nov 2018 08:52:47 +1300

> Reject the request until the CA is present

In the autonomic network ("professionally managed") scenario, I
would think of it more as a pre-fetch: somebody has pre-fetched
a nonceless voucher when the pledge was added to inventory, so
there's no need to connect to the MASA in real time.

In an on-demand situation, you're correct that it would be a
store-and-forward mechanism with a wait state. But that's
not ANIMA.

   Brian

---

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 28 Nov 2018 11:26:50 +0000

Hi Brian,
> > Getting back to my original question, do you see the asynchronous handling of pledge enrolment as part of the current charter of
> the working group? If yes, would you rather expect to see EST enhanced to handle asynchronous support or would it be better to
> allow for alternative enrolment protocol support on the domain registrar featuring the handling of self-contained objects? As the
> domain registrar is likely to be not a constraint device as a pledge, this choice could technically be provided, while the pledge has the
> freedom to choose, which enrolment to use.
> 
> I don't see any reason why the pledge-proxy-registrar chain would change in any way. It's only obtaining the voucher that needs to be
> asynchronous, to avoid the need for real-time communication with the MASA.

[stf] The communication chain as pledge-proxy-registrar would not change. Following your argumentation I actually see two asynchronous objects. One is the voucher (for which I thought the nonce-less variant could be used as asynchronous object). The other one is the PKCS#10 request. If the RA/CA is a separate component, to which the domain registrar has not a synchronous connection, the certificate request also needs to be handled in an asynchronous way. The domain proxy for instance may collect several certification requests from enrolling pledges and forward the requests to the RA/CA when available. 

Steffen

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Nov 2018 08:47:42 +1300

> [stf] The communication chain as pledge-proxy-registrar would not change. Following your argumentation I actually see two asynchronous objects. One is the voucher (for which I thought the nonce-les…

Yes, I think we are in agreement, +- some terminology.

    Brian