Re: [Anima] BRSKI-AE text proposal: how to signal to a pledge which BRSKI variant(s) with which parameter(s) a registrar supports

[Toerless Eckert <[e-mail]>]

Thanks, David

I have some more fundamental concerns than the discussions that we had this week
and that you tried to sommarize, so let me try to restate the issue in a way that
readers with less context detail can hopefully follow.

In BRSKI, the overall sequence of events is high level:
   1. Pledge discovers (somehow) BRSKI registrar, which is specified to MUST support EST.
   2. Pledge connects to registrar, TLS
   2.1 Pledge requests a voucher over the TLS connection.
   2.2 If 2.1 is successful, pledge requests EST enrollment over same TLS connection

Now, with BRSKI-AE, some set of pledges may only support some other enrollment
protocol, such as CMP instead of EST. So, the above method stays the same, except that
in 2.2, EST is replaced with e.g.: CMP.

Now the problem is that for this to work "guaranteed", pledges would need to be able to
discover a Registrar that supports (one of) the same enrollment protocol(s) as the pledge.

We have started to work on such discovery solutions across the different BRSKI extension,
including AE, but the authors of BRSKI-AE where trying to find the best solution how
to make this work best in the absence of such a discovery mechanism. 

A) For once, there is the hope that by having such a "fallback" solution (no correct discovery
of supported enrollment protocol on registrar), that the reference to a working discovery
solution could become informational only as opposed to normative.

I am not quite clear about whether or not a reference to a discovery solution should
be normative or information, whether or not we do have some better or worse fallback.
Practically speaking, i don't believe that a normative reference does necessarily help
in practical deployments. For example, assume we would specify only a GRASP discover
in such a reference, and then a deployment can not use GRASP and needs another discovery
solution anyhow. Aka: a loose linkage that is informational could IMHO say
"MUST support _some_/_whatever_/_you_pick_ discovery, such as <grasp-reference>" would
be appropriate in my book, and having e.g.: <grasp-reference> be informational. But
on this point, mileage will vary, so thats a separate question we should investigate
with folks with IESG experience.

B) The core issue really is: If we assume that we do NOT have a working discovery,
but only RFC8995 BRSKI discovery, then we may persistently learn about registrars
that will NOT support the enrollment protocol required by the pledge.

Lets say the example is that a domain has two registrars, one with EST, one with CMP,
and the discovery mechanism from rfc8995 can not help to distinguish, and now, the
most important issue that we need to tackle is that all RFC8995 compliant pledges
could persistently discover the CMP registrar first before the EST registrar, because
for example the existing discovery mechanisms persistent ordering rules of responses.

These RFC8995 pledges are a bigger pain that BRSKI-AE/CMP pledges, because currently
the brski-ae draft does not claim to update RFC8995, so we can not assume that any
useful text we write into brski-ae will be honored by those RFC8995 pledges.

So, if we want to be 100% sure that the deployment of an additional BRSKI-AE/CMP
registrar will not negatively impact any existing RFC8995 pledges, we would have to use
completely incompatible discovery parameters, so legacy pledges will never discover
the new BRSKI-AE/CMP registrar. For example using in DNS a new service name
'brski2-registrar'/brski2-proxy or the like.

Given how i think we do not have crucial production deployments of BRSKI that
we would need to protect in this way, i think we do not need to do this, because it's
always ugly to leave trash of first-gen work around, especially in registries. Instead,
we may rather want to document in brski-ae these risks after we've worked through the
cases, and maybe also use the tool of updating RFC8995 with BRSKI-AEonce we agree
on the solution we like (and see that we get easier solutions with fixing up
BRSKI requirments).

So, i have a hard time to extract from rfc8995 the likely worst-case common
behavior of an RFC8995 pledge in case of a failure.

E.g.: Lets assume we use the voucher extension approach, so an improved 'BRSKI-AE'
pledge's voucher request will contain the list of supported enrollment protocols,
and in converse, a BRSKI-AE registrar can deduce that a voucher request comes
from a non-BRSKI-AE (EST-only) pledge. What error code should it return to such a
pledge ?

Or would the registar better return a 30x error code to directly redirect the
pledge to the EST registrar. IMHO: If we think that we can improve the likelyhood
that RFC8995-only pledges can overcome issues in the presence of new BRSKI-AE registrars
by such a redirect, then i think we should add a "SHOULD be able to redirect RFC8995
pledges to a known/discovered RFC8995 registrar".

In addition: I am still a fan of new pledges trying to figure out what the registrar
can do - like we can do in CoAP. But i'll have to ask around if/how this would be
feasible with existing IETEF work.

Cheers
    Toerless

On Wed, Sep 06, 2023 at 10:31:36PM +0200, David von Oheimb wrote:
> Dear ANIMA WG,
> 
> as mentioned in the below email and in the status report at IETF 117, the
> BRSKI-AE draft would be ready for AD review,
> except that after end of WGLC, a rather general open issue with all upcoming
> BRSKI variants has been brought up by Toerless,
> namely how to signal to the pledge the capabilities of the registrar, i.e,
> which BRSKI variant(s) it supports with which parameter(s).
> 
> After some forth and back, as far as the BRSKI-AE draft is concerned, it
> should be sufficient to extend its currently very brief section:
> 
> > *4.2.1.<https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae#section-4.2.1>Pledge
> > - Registrar Discovery <https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae#name-pledge-registrar-discovery>*
> > The discovery is done as specified in [RFC8995
> > <https://www.rfc-editor.org/info/rfc8995>].
> 
> with some guidance, such as the following text:
> 
> > The pledge discovers the registrar basically as specified in [RFC8995
> > <https://www.rfc-editor.org/info/rfc8995>].
> > In an engineered environment, the pledge may simply assume that the
> > discovered registrar
> > supports the BRSKI-AE variant of BRSKI with the certificate enrolment
> > protocol it wants to use.
> > 
> > Note: In case the protocol is not supported by the registrar, this would
> > be detected only after
> > the pledge sent its certificate enrolment request, on which it would
> > receive an error (likely at HTTP level).
> > This late detection might be avoided in several ways.
> > The registrar might be able to determine by inspecting the IdevID used
> > by the pledge in the voucher request
> > which enrolment protocol the pledge is going to use and reject the
> > voucher request if it does not support this protocol.
> > The pledge could also include in its voucher request an explicit
> > indication which enrolment protocol it is going to use,
> > such that the registrar can safely reject the request if it does not
> > support this protocol. This may be achieved by
> > a simple optional extension of the voucher request structure with a
> > key-value pair,
> > where absence implies "EST" as the default protocol, and currently the
> > only other defined value would be "CMP".
> > 
> > As a more general solution, the discovery mechanism by BRSKI may be
> > extended to provide beforehand to the pledge
> > explicit information on the capabilities of the registrar, such as the
> > certificate enrolment protocol(s) it supports.
> > This needs to be specified a separate document; at the time of writing
> > this specification, it is being done in [TDB informative reference
> > toBRSKI-discovery <https://github.com/anima-wg/brski-discovery/blob/main/draft-ietf-anima-brski-discovery.md>].
> > 
> This topic, including the current state of the proposal, is meanwhile being
> handled at https://github.com/anima-wg/anima-brski-ae/issues/32.
> If you have any thoughts to share on it, I ask you to let us know by email
> or by commenting on that page.
> In particular, in case you have objections, please raise them to the draft
> authors by the end of next week.
> 
> Regards,
> 
>     David
> 
> 
> On 02.05.23 16:56, David von Oheimb wrote:
> > Dear Brian, Toerless, Michael, et al.,
> > 
> > thank you
> > 
> >   * Brian for your comment during the WGLC,
> >   * Toerless for your further quick shepherd review thereafter, and
> >   * Michael for your response on the latter on how to reference EST,
> > 
> > 
> > all quoted below.
> > 
> > I've meanwhile prepared an intermediate version of the draft that is not
> > yet officially submitted to IETF,
> > i.e., a preview of version 05, available at
> > https://github.com/anima-wg/anima-brski-ae
> > 
> > The change log so far is:
> > 
> >   * Remove entries from the terminology section that should be clear
> >     from BRSKI
> >   * Tweak use of the terms IDevID and LDevID and replace PKI RA/CA by
> >     RA/CA
> >   * Add the abbreviation 'LwCMP' for Lightweight CMP to the
> >     terminology section
> >   * State clearly in Section 5.1 that LwCMP is mandatory when using CMP
> >   * Change URL of BRSKI-AE-overview graphics to slide on IETF 116
> >     meeting material
> > 
> > 
> > The first two items were suggested internally by Steffen,
> > while the remaining ones address the below points by Toerless and Brian.
> > 
> > Regarding the reference to EST, the authors discussed this and came to
> > the conclusion
> > that we better keep the reference to EST [RFC 7030] as /informative/
> > because we do not really depend on its contents
> > since the EST instance of BRSKI-AE has effectively been removed from the
> > draft (and just remain as a theoretical option).
> > The only "feature" that stems from EST that we take over in BRSKI-AE,
> > namely the endpoint naming scheme,
> > is already covered by the reference to BRSKI [RFC 8995], such that
> > having BRSKI as a /normative/ reference fully covers this.
> > OTOH, the references to CMP are clearly /normative/ for the case that
> > BRSKI-AE is instantiated to CMP,
> > which we have made more explicit in the upcoming version as stated in
> > the above change log.
> > 
> > Thus we believe that we have covered all open points,
> > and since the IPR poll has been finished as well,
> > the draft would be ready for being submitted and for AD review,
> > but:
> > 
> > On Thu, 2023-04-27 at 11:02 +0000, Fries, Steffen wrote:
> > To: [e-mail] <[e-mail]>
> > Subject: [Anima] Design Team Meeting discussion (April 25) on BRSKI-PRM
> > discovery with cross relation to BRSKI-AE
> > 
> > > Independent of the final solution picked, as BRSKI-AE is also
> > > enhancing the functionality of a BRSKI registrar by supporting
> > > alternative enrollment protocols, the same approach is to be
> > > intended for BRSKI-AE as well. Therefore, we will wait with the
> > > submission of an updated BRSKI-AE draft until the discussion has
> > > ended.
> > 
> > So we are holding back the draft until this has been sorted out,
> > most likely resulting in a small paragraph to be added to BRSKI-AE.
> > 
> > If there is any further comment or suggestion for improval, please let
> > us (the authors) know.
> > 
> > Best,
> > David
> > 

-- 
---
[e-mail]