On 2018-11-27 00:36, Fries, Steffen wrote: > Hi Brian > >> -----Original Message----- >> From: Brian E Carpenter <[email protected]> >> Sent: Sonntag, 25. November 2018 20:22 >> To: Eliot Lear <[email protected]>; Fries, Steffen (CT RDA ITS) >> <[email protected]> >> Cc: [email protected] >> Subject: Re: [Anima] BRSKI support for asynchronous processing >> >> On 2018-11-26 02:09, Eliot Lear wrote: >>> Hi Steffen >>> >>> >>>> On 23 Nov 2018, at 20:27, Fries, Steffen <[email protected]> wrote: >>>> >>>> Hi Eliot >>>> >>>>>> 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. >>>> >>>> I assumed it to be collocates with the RA and that the CA is separate. >>> >>> Ok, well there we have it ;-) >>> >>>>> >>>>>> >>>>>> 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. >>>>> >>>>> >>>>> 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. >>>> >>>> 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. >>> >>> >>> 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. >> >> 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.
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 >> >> 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 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
