Re: [Anima] BRSKI support for asynchronous processing

2018-12-05 Thread Fries, Steffen 
Michael Richardson  wrote: 
> > 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.
> 
> BRSKI is simply the mechanism to create a secure channel.
> What happens afterwards is up to EST-RFC7030 (or something else, but the 
> ANIMA ACP specifies EST-RFC7030).
I realized the exclusive close binding to EST and was questioning this based on 
some use cases mentioned in an 
earlier email like enrolling device in a plant / building / train wagon. I 
completely understand the mandatory 
support on the domain registrar side but not the pledge side.  My understanding 
from ANIMA ACP is that 
one has to support EST on an ACP node in any case, even if a different 
enrollment protocol is used. 
It may not be a problem for new products, but existing products leveraging the 
voucher approach 
may need to be adopted more than functionally necessary. Also, if 
self-containment of the certification 
request would help to address asynchronous use cases, EST as is may have  some 
restrictions. 

 
> 7030 section 4.2.3 says, near the end:
> 
>If the server responds with an HTTP [RFC2616] 202, this indicates
>that the request has been accepted for processing but that a response
>is not yet available.  The server MUST include a Retry-After header
>as defined for HTTP 503 responses.  The server also MAY include
>informative human-readable content.  The client MUST wait at least
>the specified "retry-after" time before repeating the same request.
>The client repeats the initial enrollment request after the
>appropriate "retry-after" interval has expired.  The client SHOULD
>log or inform the end-user of this event.  The server is responsible
>for maintaining all states necessary to recognize and handle retry
>operations as the client is stateless in this regard; it simply sends
>the same request repeatedly until it receives a different response
>code.  All other return codes are handled as specified in HTTP
>[RFC2616].
> 
> so a delayed reply is permissible.
Yes, the pledge may retry, but there are certain restrictions:
- You either have to keep the TLS connection open (as you mentioned below) or 
perform resumption. 
  Depending on the use case, you may not have a direct connection to the CA so 
it may take some 
  time before the certificate will be provided. If you chose resumption the 
pledge needs to generate 
  a new PKCS#10 request to take the changed tls_unique into account. This will 
also require the EST 
  server to keep track of repeated certification requests from the same pledge. 
I also made some 
  further notes below in your list.
- If the RA/CA is not directly reachable, the authorization decision for the 
certification request needs 
  to be done on the EST server (well, this is actually also the case for the 
online case). Not a problem 
  if the RA is co-located with the Domain Registrar. If the RA/CA are located 
in the operators backend, 
  the Domain Registrar would basically perform a store and forward of the 
certification request/response
  and may not be involved directly in the authorization. The binding to the 
requesting identity 
  would be removed after the first EST server and not be visible to the 
(backend) RA. Besides 
  authorization also the tracking of components is often done in the central 
location in conjunction 
  with the RA. 
  An example may be a train wagon in which the components shall be equipped 
with the certificates 
  of the new owner.  The domain is basically the wagon and issuing certificates 
would be done in the 
  railway companies backend once the wagon is connected. To prepare this, the 
components in the 
  wagon can already prepare this be registering locally at the domain 
registrar. 

> BRSKI could perhaps be more clear about whether the pledge is expected to:
>  1) keep the TLS connection open.
Probably the best to have less recreation of PKCS#10 requests

>  1B) do this virtually via TLS session resumption ticket
Possible but requires to recreate the PKCS#10 request with the new tls_unique 
value

>  2) if it closes it, should it keep track of the Registrar certificate?
Definitely to ensure it is

Re: [Anima] BRSKI support for asynchronous processing

2018-12-02 Thread Michael Richardson 

Fries, Steffen  wrote:
> 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.

BRSKI is simply the mechanism to create a secure channel.
What happens afterwards is up to EST-RFC7030 (or something else, but the ANIMA
ACP specifies EST-RFC7030).

7030 section 4.2.3 says, near the end:

   If the server responds with an HTTP [RFC2616] 202, this indicates
   that the request has been accepted for processing but that a response
   is not yet available.  The server MUST include a Retry-After header
   as defined for HTTP 503 responses.  The server also MAY include
   informative human-readable content.  The client MUST wait at least
   the specified "retry-after" time before repeating the same request.
   The client repeats the initial enrollment request after the
   appropriate "retry-after" interval has expired.  The client SHOULD
   log or inform the end-user of this event.  The server is responsible
   for maintaining all states necessary to recognize and handle retry
   operations as the client is stateless in this regard; it simply sends
   the same request repeatedly until it receives a different response
   code.  All other return codes are handled as specified in HTTP
   [RFC2616].

so a delayed reply is permissible.
BRSKI could perhaps be more clear about whether the pledge is expected to:
 1) keep the TLS connection open.
 1B) do this virtually via TLS session resumption ticket
 2) if it closes it, should it keep track of the Registrar certificate?
 3) alternatively, should it try again and expect a voucher to be presented?
   (which gets into: whether it records the nonce, and is happy with a
   replay of the nonced voucher it got before)



{I found the non-standard quoting styles and HTML parts made the thread
incredibly difficult to follow.  We have access to WG lists via IMAP,
so you can use quite a number of programs other than what your IT department
expects you to use for email.}

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI support for asynchronous processing

2018-12-02 Thread Brian E Carpenter 
On 2018-12-03 06:44, Michael Richardson wrote:
> 
> Brian E Carpenter  wrote:
> > 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".
> 
> I think that "My suggestion" refers to the OASA concept?
> 
> I believe that it creates new protocol in the form of extensions to 8366
> processing.  

Possibly. I haven't gone into the details.

> I think it also requires the Registrar to contact the OASA
> (overriding the MASA URL in the IDevID), but maybe you have another idea.

No, exactly that. 

Brian

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

Re: [Anima] BRSKI support for asynchronous processing

2018-12-02 Thread Michael Richardson 

Brian E Carpenter  wrote:
> 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".

I think that "My suggestion" refers to the OASA concept?

I believe that it creates new protocol in the form of extensions to 8366
processing.  I think it also requires the Registrar to contact the OASA
(overriding the MASA URL in the IDevID), but maybe you have another idea.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI support for asynchronous processing

2018-12-02 Thread Michael Richardson 

Brian E Carpenter  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.

So you are looking for a kind of transitivity in vouchers.
The long-lived voucher points to an intermediary, and that intermediary can
further delegate.  I originally described such a situation back in 2014.

This is from my bookmarks, I hope it's the right bookmark, as I'm writing
this offline (above Torchwood):
  
https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00

Such a system also supports resale, with the caveat that the secondary
vendors can potentially reassert their ownership!

A different system, which I'm writing up now in response to the reviews, is
that the the original vendor supports replacing the IDevID.  This permits the
first owner to change their root trust anchor to them.  They then become the
MASA for the next owner.   This requires no new protocol mechanisms.

This permits a number of scenarios including:
   1) resale without OEM permission
   2) "off-line" MASA/OASA as you describe above.
   3) ship-to-aggregator-and-forget
   4) death of OEM.

However, it requires the device to go through an enrollment cycle prior to
death of OEM, and it requires the OEM to permit the IDevID anchor to be
replaced (and the replacement to persist through factory resets).
It is not clear to me that many vendors will be willing to do this, however,
it is really the ultimate "root"ing of the device, and the OEM very
clearly no longer has any warantee or liability if this is done.

There are some half-transfer mechanisms were one could consider if the LDevID
is permitted to be used, leaving the IDevID also available.  This seems
mechanically easy, but seems to open many issues.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[




signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI support for asynchronous processing

2018-11-28 Thread Brian E Carpenter 
On 2018-11-29 00:26, Fries, Steffen wrote:
> Hi Brian,
>>> [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.
> 
> [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. 

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

Brian

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

Re: [Anima] BRSKI support for asynchronous processing

2018-11-27 Thread 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

2018-11-27 Thread 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

2018-11-27 Thread 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

2018-11-27 Thread 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

2018-11-27 Thread 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

2018-11-27 Thread 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

2018-11-27 Thread 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

Re: [Anima] BRSKI support for asynchronous processing

2018-11-26 Thread Fries, Steffen 
Hi Brian 

-Original Message-
From: Brian E Carpenter  
Sent: Sonntag, 25. November 2018 20:22
To: Eliot Lear ; Fries, Steffen (CT RDA ITS) 

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

Re: [Anima] BRSKI support for asynchronous processing

2018-11-26 Thread Fries, Steffen 
Hi Eliot
I assumed it to be collocates with the RA and that the CA is separate.

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

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

Re: [Anima] BRSKI support for asynchronous processing

2018-11-25 Thread Brian E Carpenter 
On 2018-11-26 02:09, Eliot Lear wrote:
> Hi Steffen
> 
> 
>> On 23 Nov 2018, at 20:27, Fries, Steffen  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.

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

Brian

Brian

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

Re: [Anima] BRSKI support for asynchronous processing

2018-11-25 Thread Eliot Lear 
Hi Steffen


> On 23 Nov 2018, at 20:27, Fries, Steffen  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.

Right?

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

2018-11-23 Thread Fries, Steffen 
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.


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.

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

Re: [Anima] BRSKI support for asynchronous processing

2018-11-23 Thread Eliot Lear 
Hi Steffen

> On 23 Nov 2018, at 17:53, Fries, Steffen  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 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.

Eliot


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

[Anima] BRSKI support for asynchronous processing

2018-11-23 Thread Fries, Steffen 
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

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