[Anima] Constrained-BRSKI proposed optimization: Pledge doesn't send root CA cert

[Esko Dijk]

All,

At IETF115 I mentioned an open issue for constrained BRSKI is about a proposed 
optimization. Feedback is requested on this!

The idea is that the Pledge does not send the root CA certificate, as part of 
the Client Certificate message of the DTLS handshake with the Registrar.

In TLS/DTLS 1.2 this root CA cert is optionally excluded, as per below text 
from RFC 5246:

  the self-signed certificate that specifies the root
  certificate authority MAY be omitted from the chain, under the
  assumption that the remote end must already possess it in order to
  validate it in any case.

For constrained BRSKI we could RECOMMEND the Pledge to do this, to reduce data 
size on constrained networks and speed up the process.

The assumption on the Registrar is then that either one of these two cases hold:

  1.  Known vendor and/or sales integration: the domain owner Registrar already 
has the vendor’s root CA cert for the product(s) the owner wants to bootstrap. 
This it uses during handshake client verification.
  2.  Unknown vendor and no sales integration: the Registrar can on-the-fly 
identify the Pledge based on the presented IDevID certificate in the handshake, 
and fetch the vendor’s root CA cert by connecting to the MASA server over TLS.

See also Github issue 
https://github.com/anima-wg/constrained-voucher/issues/239.

So if a Pledge vendor sells only under model 1), then excluding the root CA 
cert is always fine.
If a vendor sells under model 2) always or sometimes, then excluding the root 
CA cert is fine under the condition that the TLS connection to the MASA will 
provide the needed root CA cert.  If that MASA TLS connection is authenticated 
otherwise (e.g. something exotic like PSK from a QR code, or using an identity 
from public PKIX hierarchy not related to the Pledge’s root CA) then it implies 
the Pledge MUST include the root CA cert in its Client Certificate message.

Therefore, what we achieve is a substantial savings of over-the-wire data for 
the common cases.

If the proposed solution for model 2) above sounds too restrictive, an 
alternative idea is to define a new HTTPS resource on the MASA server under the 
path “/.well-known/brski/cacerts” which contains all the root CA certs for all 
Pledges that are supported by that MASA. This HTTPS resource is only strictly 
required if the vendor makes Pledges that omit the root CA certificate in the 
handshake.

Regards
Esko
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] WGLC for draft-ietf-anima-brski-cloud-05, ends Nov. 28th, 2022

[Esko Dijk]

Hi all,

Since the WGLC period is now past let me post my viewpoint: the draft is not 
yet ready. Some editorial updates are to be done by the WG and the YANG module 
definition needs fixing.
I will provide my comments as Github PRs in the coming days, which should make 
it easiest to integrate. There I will propose changing "EST Registrar" to "EST 
server".

Regards
Esko

-Original Message-
From: Anima  On Behalf Of Esko Dijk
Sent: Monday, November 21, 2022 10:41
To: Anima WG ; draft-ietf-anima-brski-cl...@ietf.org
Subject: Re: [Anima] WGLC for draft-ietf-anima-brski-cloud-05, ends Nov. 28th, 
2022

Hello all,

I'm reviewing the draft currently and agree it needs at least one more editing 
pass. So far no technical issues came up, only editorial ones and YANG-nits.

To help write up my review comments I do have these questions to the authors:

- should I provide my comments in email, as Github issues, or Github PRs? (any 
preference)

- what is the "EST Registrar"? It is not defined so far. Wouldn't it be better 
to use RFC 8995 terminology of "EST server" ?   So if the cloud Registrar 
supplies the Voucher and that redirects to an owner's EST server, we can call 
that "EST server" or "owner EST server".  It's not a Registrar, so not "EST 
Registrar" or "owner Registrar".The latter term is already used for the 
server that provides a voucher to the pledge.
 (Interesting to consider that the owner's EST server *could* be a Registrar 
i.e. handing out vouchers in theory, even if the 
cloud-Registrar-supporting-pledge already got its voucher from the 
cloud-Registrar.  But let's not say such things in the document to avoid 
complicating it.)

- the YANG contains "RFC : Voucher Profile for Cloud redirected Devices" - 
it seems the name needs updating and there should be an RFC ednote here saying 
the reference is "this RFC". Correct?

- YANG contains this:
 description "Base the constrained voucher upon the regular one";
This looks like a copy/paste leftover from constrained-voucher; correct that it 
should be modified? (Would this also bump the YANG version and date then?)

- YANG description for leaf "est-domain" does not explicitly say the word "EST 
server" which I think it should. So this URI directs to the EST server in the 
owner's domain.

- could YANG support the use case of combining the voucher-constrained  format 
(that extends base voucher) and the voucher-redirected format (from current 
draft) ?  Would that require yet another new YANG module?

Regards
Esko

-Original Message-
From: Anima  On Behalf Of Brian E Carpenter
Sent: Sunday, November 20, 2022 22:27
To: Anima WG 
Subject: Re: [Anima] WGLC for draft-ietf-anima-brski-cloud-05, ends Nov. 28th, 
2022

Hi,

Summary:


This draft is very clear and almost ready, but I think it needs one more 
editing pass. I have some minor substantive comments followed by some nits.

Substantive comments:
=

> Abstract

This is a bit short. I think it should provide a little context for a casual 
reader (what is BRSKI, what is a pledge, what is a registrar).

>  1. Introduction
> 
> Bootstrapping Remote Secure Key Infrastructures [BRSKI] specifies automated 
> bootstrapping of an Autonomic Control Plane.

Not quite. It specifies secure bootstrapping of the individual nodes. It's RFC 
8994 that bootstraps the ACP.

>  2. Architecture
> 
> The high level architecture is illustrated in Figure 1.

I find the "??" in the figure confusing. The Cloud Registrar and the MASA could 
just be shown as adjacent boxes; the explanation in the text is fine.

> TWO CHOICES: 1. Cloud Registrar redirects to Owner Registrar 2. Cloud 
> Registrar returns VOUCHER pinning Owner Register.

That looks ugly as a single pseudo-sentence, and I'm not sure what it means. A 
more complete explanation would be good.

>  2.1. Interested Parties 

I find this section too telegraphic. Needs a bit more grammar...

>  2.2. Network Connectivity
> 
> The assumption is that the pledge already has network connectivity prior to 
> connecting to the cloud registrar. The pledge must have an IP address, 

Should specify that you mean "routeable" IP address, I think. (I suppose it 
could be a ULA in some deployments?)

>  2.3. Pledge Certificate Identity Considerations
> ...
> EST [RFC7030] is not clear on how the CSR Attributes response should be 
> structured, and in particular is not clear on how a server can instruct a 
> client to include specific attribute values in its CSR. 
> [I-D.richardson-lamps-rfc7030-csrattrs] clarifies how a server can use CSR 
> Attributes

I'm not entirely comfortable with this being an Informative reference. Isn't 
this essential for interoperable implementations?

Nits:
=

>  1.2. Target Use Cases
> ...
> for many smaller sites (such as teleworkers) no further infrastructure are 
> expected.

s/are/is/

> ...
> While a Cloud Registrar will typically handle all the devices of a particular 
> product line from a