Re: [Anima] BRSKI support for asynchronous processing

[Brian E Carpenter]

On 2018-11-28 02:11, Eliot Lear wrote:
> Hi Steffen
> 
>> On 27 Nov 2018, at 11:49, Fries, Steffen  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

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

> 
> 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
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI support for asynchronous processing

[Brian E Carpenter]

On 2018-11-28 00:49, Fries, Steffen wrote:
> Hi Eliot
...
>>> 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?
>> 
>> Yes, several.
>> 
>> First, there is now a mailing list that is related to this, 
>> iot-onboard...@ietf.org.  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.

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

>> 
>> 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.

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

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI support for asynchronous processing

[Brian E Carpenter]

Hi Eliot,
On 2018-11-27 23:04, Eliot Lear wrote:
> 
> 
>> 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?
> 
> Yes, several.
> 
> First, there is now a mailing list that is related to this, 
> iot-onboard...@ietf.org .  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"

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 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.

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

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI support for asynchronous processing

[Fries, Steffen]

Hi Eliot
On 27 Nov 2018, at 11:49, Fries, Steffen 
mailto:steffen.fr...@siemens.com>> 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:
[stf] okay :-)

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
[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

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI support for asynchronous processing

[Eliot Lear]

Hi Steffen

> On 27 Nov 2018, at 11:49, Fries, Steffen  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



signature.asc
Description: Message signed with OpenPGP
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI support for asynchronous processing

[Fries, Steffen]

Hi Eliot
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?

Yes, several.

First, there is now a mailing list that is related to this, 
iot-onboard...@ietf.org.  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
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI support for asynchronous processing

[Eliot Lear]

> 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?

Yes, several.

First, there is now a mailing list that is related to this, 
iot-onboard...@ietf.org .  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"

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



signature.asc
Description: Message signed with OpenPGP
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima