Subject: [Anima] Questions raised during IETF 105 regarding BRSKI-AE

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 22 Aug 2019 10:38:05 +0000

Hi,

during IETF 105, there were several questions raised regarding motivation and approach in BRSKI-AE (https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll/ )
I just checked the recordings and would like to provide some answers. Thanks Eliot for presenting in the first place.

There was a question regarding the benefits on Full CMC (PKI) Request support in EST from Michael. One of the benefits of the Full CMC request is that it provides a way to bind the entity identification and authentication to the certification request. This can be achieved by an additional signature over the certification request with the IDevID EE cert of a pledge. The result is what we called in the draft a self-contained object with two signatures, one with the private key corresponding to the contained public key in the CSR, the second with the private key, which's corresponding certificate can be validated.  Maybe the term is misleading as the CSR is also self-contained. So we may need to fine a better term. 
Having this type of self-contained object comes with some advantages:
- It removes the strict binding of the  certification request with the pledge authentication in TLS using the tls-unique value in the CSR during the EST run. This is especially interesting for scenarios, in which the registrar (EST server) acts as LRA and has (temporarily) no connection to the issuing RA/CA. If it needs to store the CSR and forward it later on for further processing to the RA/CA, the information about the identity and authentication is not directly bound to the CSR and would require other mechanisms. 
- For the "no soup case - come back later" case (Eliot, I just borrowed your analogy)  it provides the advantage, if the tls-unique parameter is used in the CSR (BRSKI is open to this) to bind the CSR to a specific TLS connection. If the TLS connection between the pledge and the registrar was teared down, EST (in simple enroll/reenroll) requires to resent the CSR, which would require to include a new tls-unique number, which in turn would require rebuilding the CSR (also described in RFC 7030, section 4.2.3).

The advantages of self-containment (in the case of EST using the FullCMCrequest) are not generally necessary, but there are scenarios, in which the pure binding of the pledge authentication using its IDevID EE Cert to the transport is not sufficient (see also the examples in BRSKI-AE). Note that using self-containment also addresses the general case. From that point I would see BRSKI-AE as update/enhancement of the mechanisms currently used in BRSKI. From my understanding this was also the outcome of the conversation during the meeting. 

Best regards
Steffen

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Aug 2019 17:18:53 -0400

Fries, Steffen <[email-masked]> wrote:
    > There was a question regarding the benefits on Full CMC (PKI) Request
    > support in EST from Michael. One of the benefits of the Full CMC
    > request is that it provides a way to bind the entity identification and
    > authentication to the certification request. This can be achieved by an
    > additional signature over the certification request with the IDevID EE
    > cert of a pledge. The result is what we called in the draft a
    > self-contained object with two signatures, one with the private key
    > corresponding to the contained public key in the CSR, the second with
    > the private key, which's corresponding certificate can be validated.
    > Maybe the term is misleading as the CSR is also self-contained. So we
    > may need to fine a better term.

okay.  I need to re-read things to better understand.

    > - It removes the strict binding of the  certification request with the
    > pledge authentication in TLS using the tls-unique value in the CSR
    > during the EST run. This is especially interesting for scenarios, in
    > which the registrar (EST server) acts as LRA and has (temporarily) no
    > connection to the issuing RA/CA. If it needs to store the CSR and
    > forward it later on for further processing to the RA/CA, the
    > information about the identity and authentication is not directly bound
    > to the CSR and would require other mechanisms.

    > - For the "no soup case - come back later" case (Eliot, I just borrowed
    > your analogy)  it provides the advantage, if the tls-unique parameter
    > is used in the CSR (BRSKI is open to this) to bind the CSR to a
    > specific TLS connection. If the TLS connection between the pledge and
    > the registrar was teared down, EST (in simple enroll/reenroll) requires
    > to resent the CSR, which would require to include a new tls-unique
    > number, which in turn would require rebuilding the CSR (also described
    > in RFC 7030, section 4.2.3).

I agree that this is a good feature.
Can you tell us more about how you'd use it?

My next question would be, given that some would like CMP rather than EST as
an option, and it appears that LAMPS may do a minimal profile of CMP, maybe
that would suit you better for these disconnected uses rather than fullcmc.

Regardless, how would one discover and signal the use of fullcmc or CMP?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 26 Aug 2019 06:10:26 +0000

Hi Michael,

> From: Michael Richardson <[email-masked]>
[stf] the essential point is to have the binding of the authentication using IDevID EE credentials directly on the CSR instead of indirectly using the communication link. We definitely need a better term as self-containing may be misleading.
> Can you tell us more about how you'd use it?
[stf] Retry in EST is done by resending the CSR is after the signaled retry after period in the 202 message from the server. The server must keep track of all states necessary to assign the try request to an already received request. Other protocols provide a request identifier, which can be leveraged to ask for the certificate using the request identifier based on the initially provided CSR.
> 
> My next question would be, given that some would like CMP rather than EST as an option, and it appears that LAMPS may do a
> minimal profile of CMP, maybe that would suit you better for these disconnected uses rather than fullcmc.
[stf] The intention of lightweight CMP is to reduce the versality of CMP down to what is necessary in typical industrial or IoT scenarios. It can be used in a similar way as FullCMC and thus it can be used to address the BRSKI-AE case. As stated in BRSKI-AE draft, the message wrapping with signature provided in CMP and FullCMC provides the binding to the initial authentication on an object base. That said, I would propose to let the registrar support multiple enrollment protocols to be able to handle different deployment environments.

> Regardless, how would one discover and signal the use of fullcmc or CMP?
[stf] EST provides this option by using the well-known URI approach. It specifies this for /simpeenroll and /simplereenroll, but also for /fullcmc. In BRSKI-AE we followed that path and utilized the same mimic and proposed "/.well-known/enrollment-variant/request". This would allow to support different options on the Registrar side and let the pledge pick one.

Best regards
Steffen
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-