Subject: Re: [Anima] BRSKI-AE document split discussion

From: "[email-masked]" <[email-masked]>
Date: Thu, 2 Sep 2021 15:55:03 +0200

Using this thread: We had a good first discussion about the subject
on last thursdays BRSKI-DT call and hopefully will continue it over the coming
ones.

While initially the split into two documents sounded like a useful option
based on the two separate reference architecture pictures for the
two separate use-cases == scenarios, i began to question whether the
use cases of interest would be able to support combinations of both
scenarios.

Scenario 1 introduces a "offline-site", e.g.: manufacturing plant, with
an extended registrar to support the offline backend connectivity
to MASA and CA-infra.

Scenario 2 introduces a pledge that is not initiating enrollment as
in BRSKI, but at most supporting some link-local discovery protocol
(e.g.: mDNS) and would prefer to speak afterwards a protocol wher
it is the responder, as normal in Netconf, opposed to being the
initiator as normal in BRSKI. 

To me it looked very likely that the typical use-case of a manufacturing
plant would often want to have a combination of both scenarios:
The manufacturing plant might prefer to not be connected to the
Internet (== scenario 1) AND pledges want to be of the type defined
via Scenario 2.

So, while this does not say that we may not want to split up the document
into 2 in the end, it means that i would very much like to see that 
the document adds a single integrated combined reference picure and
then explores how it would be possible to combine them, so that we do
not end up creasting two incompatible solutions and forego the option
to build this combined scenario.

There is of course also always the variability in protocol options
specific industries prefer, and i would like to avoid having to re-specify
more than just the bare minimum when this happens instead of having to
repeat a lot of redundant normative text because we are missing a
good architecural reference document to which one can refer when adding
yet another protocol or crypto option in one part of the solution.

Meaning: I would not exclude the option yet, to split the document in
3: One that is the inclusive "reference/architecture" document that
we keep alive and extend with whatever we need to keep in common,
and then 2 or maybe over time more protocol specification parts of
the pieces we are adding.

So, just tactically, maybe just start putting a new section with
combined picture into the document, informationally discussing the
things that would need to happen (protocol wise) or this combination.

Cheers
    Toerless

On Wed, Aug 25, 2021 at 02:32:20PM +0000, Fries, Steffen wrote:
> Hi Toerless,
> 
> Just using the previous thread to ask if there has been a decision regarding the document split of BRSKI-AE, we proposed during IETF 111.
> 
> Best regards
> Steffen
> 
> > -----Original Message-----
> > From: Anima <[email-masked]> On Behalf Of Michael Richardson
> > Sent: Donnerstag, 5. August 2021 15:58
> > To: Robert Wilton <[email-masked]>; [email-masked]
> > Subject: Re: [Anima] BRSKI-AE document split discussion
> > 
> > 
> > Dear Area Director and WG Chairs,
> > 
> > While I am in favour of splitting the document into two, the number of
> > documents that the IESG is willing to process is not infinite.
> > One advantage of the split is that products can more clearly articulate which RFC
> > they support.
> > (RFCXXXX vs RFCZZZZ, or RFCYYYY section A, or RFCYYYY section B)
> > 
> > Can you comment on this thread about splitting things up?
> > 
> > I also have not heard very clearly about whether or not RFC8366bis will
> > be adopted and worked on.   If reducing number of documents is important,
> > then one possibility is to merge draft-ietf-anima-jws-voucher into RFC8366bis.
> > 
> > Plus: fewer documents.
> > Negative: potentially opens up RFC8366bis to new semantics?
> > 
> > --
> > Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
> >            Sandelman Software Works Inc, Ottawa and Worldwide
> > 
> > 
> > 
> 

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Sep 2021 13:08:56 -0400

> Internet (== scenario 1) AND pledges want to be of the type defined

Will we be able to avoid normative cross-references? Probably not.
So the documents will progress together.

I think that where we will benefit will be in the review/reader point of view.

    > the pieces we are adding.

I would call the third document the applicability statement for uses in
industry FOO.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 3 Sep 2021 19:30:14 +0200

Michael:

For the joint picture that shows the async points both in the frontent (pledge)
as well as backend (Registrar) together, which document should that go into ?

I am mostly worried that we understand how the case where you have both
async points toether will work.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 3 Sep 2021 18:57:28 +0000

Hi Toerless, hi Michael

> From: Michael Richardson <[email-masked]>
> Sent: Freitag, 3. September 2021 19:09
>  
The problem space that we had in mind regarding the split should address this by: 
A: An informative document outlining the use of alternative enrollment protocols in BRSKI. As BRSKI already distinguishes between the endpoints for voucher handling and enrolment handling, the introduction of an alternative enrollment should be straight forward as outlined in the latest async draft. BRSKI is not prescriptive regarding the protocol used from the Registrar (as RA) to the CA. Handling of offline situation with respect to enrollment could thus also be part of an operational considerations document. Offline voucher exchanges are already considered in BRSKI by using nonceless vouchers. 

B: A normative document specifying responder mode of pledges. This is what use case 2 addresses by introducing the registrar-agent. Depending on the deployment, the registrar-agent may be part of a commissioning tool, to provide support when there is no connectivity to the registrar. Alternatively, the registrar-agent may be part of the registrar itself. This enables (online) interactions with pledges in initiator mode and pledges in responder mode.

> I would call the third document the applicability statement for uses in industry
> FOO.
Or it may be part of an operational considerations document that addresses different architecture deployment options. 

Regards
Steffen

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Sep 2021 16:12:33 -0400

[email-masked] <[email-masked]> wrote:
    > For the joint picture that shows the async points both in the frontent
    > (pledge) as well as backend (Registrar) together, which document should
    > that go into ?

I think that this is fluid question.

    > async points toether will work.

Whether we have 1,2,or 3 documents, I think that the risk is not that we will
underspecify, but rather than we will inadvertedly make contradictory statements.

At a certain document length, the risk of forgetting what one wrote above is
the same as forgetting how documents 1/2 relate.

---

From: "Werner, Thomas" <[email-masked]>
Date: Mon, 20 Sep 2021 07:59:46 +0000

Hello Toerless, hello Michael,

we had some further discussion on the intended functionality addressed, which was the reason for the proposed split. 

Two functional approaches are considered: 
A: Handling situations in which the pledge implements a different enrollment protocol but keeps the voucher exchange as is. BRSKI distinguishes already between voucher handling and enrollment handling through different endpoints. This distinction is used in BRSKI-AE use case 1 by showing how to utilize an alternative enrollment protocol.
BRSKI-AE use case 1 is focusing on the enrollment only and reuses the voucher handling as is. 

B: Handling situations in which there is no connection between pledge and registrar. Offline cases between the registrar and other components in the backend may already be handled using BRSKI means. In BRSKI the registrar is assumed to be the component that authorizes domain membership based on voucher exchanges and acts as registration authority (RA) for the enrollment exchanges. 
This relates to two different approaches for offline or no direct connections between pledge and registrar:
- Pledge is initiator: If the pledge is not connected to the registrar, the bootstrapping process as defined in BRSKI may not be possible as it relies on the TLS connection between the pledge and the registrar. Loosing the benefits of the TLS connection results in a new approach for BRSKI exchanges. Note temporarily offline pledges are not addressed here.
- Pledge is responder: Situation addressed by BRSKI-AE use case 2. 
  BRSKI-AE introduces the registrar-agent, which interacts with the pledge and the registrar to fetch the voucher/enrollment requests and also provides the corresponding responses. The registrar-agent itself acts as an initiator to the pledge and to the registrar. Note that the registrar-agent may be part of a commissioning tool or of the registrar itself. Registrar-agent deployment on the registrar enables online interactions with both, pledges in initiator mode or responder mode.

Based on the points above we see the problem space and propose the split: 
A: Informative document outlining the use of an alternative enrollment protocol in BRSKI.
B: Normative document specifying responder mode of pledges in BRSKI. 

Best regards
Thomas

> From: Anima <[email-masked]> On Behalf Of Fries, Steffen
> Sent: Freitag, 3. September 2021 20:57
> To: Michael Richardson <[email-masked]>; [email-masked]; [email-masked]
> A: An informative document outlining the use of alternative enrollment protocols in BRSKI. As BRSKI already distinguishes between the
> endpoints for voucher handling and enrolment handling, the introduction of an alternative enrollment should be straight forward as
> outlined in the latest async draft. BRSKI is not prescriptive regarding the protocol used from the Registrar (as RA) to the CA. Handling
> of offline situation with respect to enrollment could thus also be part of an operational considerations document. Offline voucher
> exchanges are already considered in BRSKI by using nonceless vouchers.
> 
> B: A normative document specifying responder mode of pledges. This is what use case 2 addresses by introducing the registrar-agent.
> Depending on the deployment, the registrar-agent may be part of a commissioning tool, to provide support when there is no
> connectivity to the registrar. Alternatively, the registrar-agent may be part of the registrar itself. This enables (online) interactions
> with pledges in initiator mode and pledges in responder mode.
> 
> >
> > I would call the third document the applicability statement for uses
> > in industry FOO.
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fanima&amp;data=04
> %7C01%7Cthomas-
> werner%40siemens.com%7Ced1178047ed34707b50408d96f0cbbf5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637662
> 922756618491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> 00&amp;sdata=GTub%2BiCgzD19iVeXqIlED0nkSGg2h8e1Fzd%2BgH4gsVk%3D&amp;reserved=0

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Sep 2021 18:35:44 -0400

I think that Thomas' explanation makes sense.

Split the document.  I suggest you clone the repo, and post a second copy
under a new name.