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

[Esko Dijk <[e-mail]>]

> [stf] One assumption we always had was that the registrar in the infrastructure is the more capable device, meaning that a registrar that supports BRSKI-AE would also support BRSKI contrary to a pledge, which we would assume only supports one of the options. I know, this does not help with old registrars, which get contacted by BRSI-AE pledges.

In Constrained BRSKI we use the assumption "It is assumed that all Registrars support all relevant voucher(-request) formats, while the Pledge only supports a single format."   (And the MASA naturally supports the format the Pledge uses.)
As you say this assumption could be extended also to enrollment protocols. But, this seems to have more practical issues - the domain / customer may only support a particular enrollment like EST because it's integrated into its existing certificate-handling process.
Then, although the Registrar may software-wise support CMP and EST, the CMP part may not be configured to be active, by the domain admin. Which means that any CMP-only Pledge trying to enroll would still fail.

Logically, there shouldn't even be any CMP-only Pledges coming on-site in that case because the customer/installer/admin/... would know in advance that it wouldn't work.  But sometimes logistics go wrong :(
Is it acceptable in this case that the CMP-only Pledge tries to enroll but then fails (repeatedly) ?

And the reverse could occur also - a site that only supports CMP and not EST. In that case if an EST-only "classic" Pledge is added it would also try to enroll and fail. 

One thing that could solve both cases is using different service names for CMP/EST cases. But this has the downside that it makes the Proxy discovery less generic - i.e. a (legacy) Proxy only knowing about "BRSKI-EST" would fail to advertise the "BRSKI-CMP" service to Pledges.

Esko

-----Original Message-----
From: Anima <[e-mail]> On Behalf Of Fries, Steffen
Sent: Friday, September 8, 2023 16:27
To: Toerless Eckert <[e-mail]>; David von Oheimb <[e-mail]>
Cc: Brockhaus, Hendrik <[e-mail]>; anima-chairs <[e-mail]>; Michael Richardson <[e-mail]>; [e-mail]; draft-ietf-anima-brski-ae <[e-mail]>; anima <[e-mail]>
Subject: Re: [Anima] BRSKI-AE text proposal: how to signal to a pledge which BRSKI variant(s) with which parameter(s) a registrar supports

Hi Toerless,

I put in some further thoughts inline.

Best regards
Steffen

> -----Original Message-----
> From: Toerless Eckert <[e-mail]>
> Sent: Thursday, September 7, 2023 3:32 AM
> Subject: Re: [Anima] BRSKI-AE text proposal: how to signal to a pledge which
> BRSKI variant(s) with which parameter(s) a registrar supports
> 
> 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.
[stf] I think having it optionally would be fine and ensure backward compatibility

> 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.
[stf] One assumption we always had was that the registrar in the infrastructure is the more capable device, meaning that a registrar that supports BRSKI-AE would also support BRSKI contrary to a pledge, which we would assume only supports one of the options. I know, this does not help with old registrars, which get contacted by BRSI-AE pledges.

> 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.
[stf] I understood the update was deliberately removed but is intended to be reintroduced as "extend" based on the draft you referred to from Mirja (https://datatracker.ietf.org/doc/draft-kuehlewind-rswg-updates-tag/)

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

[stf] again, if we assume the (likely) existence of a single registrar featuring both approaches BRSKI and BRSKI-AE it is not a problem. Also, for the AE pledges, if the error handling is enhanced in section 4.2.3 (https://www.ietf.org/archive/id/draft-ietf-anima-brski-ae-05.html#name-pledge-registrar-ra-ca-cert) to consider the case were there will be a timeout (no response) or an error response resulting in the deletion of the voucher on the pledge site would cover several cases. Also for the registrar, this type of enhanced error handling is possible, allowing the registrar to update the (local) state of the pledge with respect to the onboarding.  

> 
> 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".
[stf] both approaches are possible from my understanding, but need some rethinking, as the redirect would have an influence the provisional accept state handling on the pledge. 

> 
> 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.
[stf] Yes. We had that discussion already regarding the endpoint discovery, which was explained to not work with http. Unfortunately. 

> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A
> > > %2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-
> ae%
> > > 23section-
> 4.2.1&data=05%7C01%7Csteffen.fries%40siemens.com%7Cd0d214a
> > >
> a621a4787777d08dbaf424411%7C38ae3bcd95794fd4addab42e1495d55a
> %7C1%7C0
> > >
> %7C638296471376550045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLC
> > >
> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
> data=b
> > >
> k4n5GU2XhEWMnniZ1lOQfSm7ItCXm3jZ2A6k%2BpsGyE%3D&reserved=0>P
> ledge
> > > - Registrar Discovery
> > > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd
> > > atatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-ae%23name-
> > > pledge-registrar-
> discovery&data=05%7C01%7Csteffen.fries%40siemens.co
> > >
> m%7Cd0d214aa621a4787777d08dbaf424411%7C38ae3bcd95794fd4adda
> b42e1495d
> > >
> 55a%7C1%7C0%7C638296471376550045%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4
> > >
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> 7C%7C
> > >
> %7C&sdata=fjZEhnYa2x2qziIEtw24QxfrlKFkO5tnoeAeuhHR%2F1s%3D&reser
> ved=
> > > 0>* The discovery is done as specified in [RFC8995
> > >
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.rfc-
> editor.org%2Finfo%2Frfc8995&data=05%7C01%7Csteffen.fries%40siemens.c
> om%7Cd0d214aa621a4787777d08dbaf424411%7C38ae3bcd95794fd4add
> ab42e1495d55a%7C1%7C0%7C638296471376550045%7CUnknown%7CT
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3%2B8jio8N8g1%2BKhWyn
> 07n3JoUcAq0wXu0sx%2Fk4WmwwXA%3D&reserved=0>].
> >
> > with some guidance, such as the following text:
> >
> > > The pledge discovers the registrar basically as specified in
> > > [RFC8995
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.rfc-
> editor.org%2Finfo%2Frfc8995&data=05%7C01%7Csteffen.fries%40siemens.c
> om%7Cd0d214aa621a4787777d08dbaf424411%7C38ae3bcd95794fd4add
> ab42e1495d55a%7C1%7C0%7C638296471376550045%7CUnknown%7CT
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3%2B8jio8N8g1%2BKhWyn
> 07n3JoUcAq0wXu0sx%2Fk4WmwwXA%3D&reserved=0>].
> > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fanima-wg%2Fbrski-discovery%2Fblob%2Fmain%2Fdraft-ietf-
> anima-brski-
> discovery.md&data=05%7C01%7Csteffen.fries%40siemens.com%7Cd0d214a
> a621a4787777d08dbaf424411%7C38ae3bcd95794fd4addab42e1495d55a
> %7C1%7C0%7C638296471381705308%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000%7C%7C%7C&sdata=Z1hiCOg3VRgyKYaUlfWs0%2BGTxr4e%2BBOr
> XPpBNH98yR0%3D&reserved=0>].
> > >
> > This topic, including the current state of the proposal, is meanwhile
> > being handled at
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2Fanima-wg%2Fanima-brski-
> ae%2Fissues%2F32&data=05%7C01%7Csteffen.fries%40siemens.com%7Cd0
> d214aa621a4787777d08dbaf424411%7C38ae3bcd95794fd4addab42e149
> 5d55a%7C1%7C0%7C638296471381705308%7CUnknown%7CTWFpbGZsb
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3D%7C3000%7C%7C%7C&sdata=hfoOtQotYuRvAmiRhiB3IlM1SuEeWoc%
> 2BT63DWInzO1Q%3D&reserved=0.
> > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > thub.com%2Fanima-wg%2Fanima-brski-
> ae&data=05%7C01%7Csteffen.fries%40
> > >
> siemens.com%7Cd0d214aa621a4787777d08dbaf424411%7C38ae3bcd957
> 94fd4add
> > >
> ab42e1495d55a%7C1%7C0%7C638296471381705308%7CUnknown%7CT
> WFpbGZsb3d8e
> > >
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C
> > >
> 3000%7C%7C%7C&sdata=WpInfwc%2BquC8CMyGy1KzTCcVebMFyN6BzoSX
> zPPTCmw%3D
> > > &reserved=0
> > >
> > > 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]

_______________________________________________
Anima mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/anima