Subject: Re: [Anima] BRSKI support for asynchronous processing

From: Michael Richardson <[email-masked]>
Date: Sun, 02 Dec 2018 17:41:51 -0000

Brian E Carpenter <[email-masked]> 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  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Sun, 02 Dec 2018 17:44:46 -0000

Brian E Carpenter <[email-masked]> 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 3 Dec 2018 08:21:03 +1300

On 2018-12-03 06:44, Michael Richardson wrote:
> processing.  

Possibly. I haven't gone into the details.

> I think it also requires the Registrar to contact the OASA

No, exactly that. 

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 3 Dec 2018 08:28:57 +1300

> vendors can potentially reassert their ownership!

Yes. If I'm not mistaken this would still work if the manufacturer
no longer exists and its private key has been destroyed. As I think
Randy Bush said, it's not OK if a device becomes unusable when that
happens. Basically we need transfer of ownership to mean transfer
of the ability to create a voucher. 
 
> It is not clear to me that many vendors will be willing to do this, however,

But then maybe people will refuse to buy their products.

> mechanically easy, but seems to open many issues.

I think all this needs to be explored in detail. Whether that is ANIMA
business is another question.

Thanks
    Brian

---

From: Michael Richardson <[email-masked]>
Date: Sun, 02 Dec 2018 17:30:03 -0000

Fries, Steffen <[email-masked]> 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.}

---

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 5 Dec 2018 10:05:41 +0000

Michael Richardson <[email-masked]> wrote: 
> 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. 

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

>  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 taking to the same registrar afterwards. Other actions like 
the time synchronization have been done before based on the Registrar certificate. 
If that changes, what would be the consequences?

>    replay of the nonced voucher it got before)
If it records the nonce, would that conflict with the statement in BRSKI section 5.2, 
that the nonce MUST NOT be reused for multiple bootstrapping attempts? Maybe not, 
as it may not be counted as attempt as the pledge was not generating a new 
voucher request.
 
Best regards
Steffen

> 
> 
> 
> {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 <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-
> 
>