Hi Brian
-----Original Message-----
From: Brian E Carpenter <brian.e.carpen...@gmail.com>
Sent: Sonntag, 25. November 2018 20:22
To: Eliot Lear <l...@cisco.com>; Fries, Steffen (CT RDA ITS)
<steffen.fr...@siemens.com>
Cc: anima@ietf.org
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 <steffen.fr...@siemens.com> 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.
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
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
