[Anima] comments about draft-richardson-anima-masa-considerations

Toerless Eckert <tte@cs.fau.de> Tue, 10 March 2020 05:23 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682743A0819 for <anima@ietfa.amsl.com>; Mon, 9 Mar 2020 22:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAFS1xlMR4sg for <anima@ietfa.amsl.com>; Mon, 9 Mar 2020 22:23:26 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602213A0812 for <anima@ietf.org>; Mon, 9 Mar 2020 22:23:25 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3E38254842E; Tue, 10 Mar 2020 06:23:18 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 30BA8440040; Tue, 10 Mar 2020 06:23:18 +0100 (CET)
Date: Tue, 10 Mar 2020 06:23:18 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "anima@ietf.org" <anima@ietf.org>
Message-ID: <20200310052318.GA26481@faui48f.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/wqdLtVGe5Efwksx0JiCTjYkEGXI>
Subject: [Anima] comments about draft-richardson-anima-masa-considerations
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2020 05:23:29 -0000

Very interesting document.

Some alas not very structured comments:

1. tooling: would be great if you had a makefile that automatically
updates the .txt when you do a commit in github. .mkd is just 'ok',
but not 'great' to read (like .txt is).

2. "A three-tier PKI infrastructure is appropriate"

I was confused by that statement vs. the followig text. When i heard for
example "intermedia CA" in other contexts (enterprise PKI
architectures), it meant that there was another layer of CA below the
intermediate CAs, namely the "assigning CA(s)". And they called that a
three-tier PKI infrastructure too.

The reason for three tiers of CA is when you have multuple functions
within an organization that need to run CAs. The root CA is the offline
magic you described, so it not really for day to day work. The
intermediate CA are run by the enterprise security department which sets
policies which department can do what with their CAs. The departments
(like manufacturing) run the assigning ("leaf") CA.

In any case, "intermediate" sounds really as if there are more CA below it.

Related: Whether or not you want a CA in the manufacturing plant also
depends on the trust model to your likely outsourced manufacturing plant
and the tracking/control you want to exercise on it. Your headqaurter
based CA will not sign IDevIDs for the plant cousins grey market plant
across the street ;-)

3. Title etc..

Something like "IDevID, MASA and voucher considerations for BRSKI infrastructures" 
would be better matching the content.

The text also reads more like design and not operations, maybe consider if where you say "operations" (also in the text) it is really design.

4. "There are two fundamental ways to generate IDevID certificates ..."

But then you have 3 bullet points.

5.  Key generation process

I think the different mechanisms you describe also exist to support
other systems than those that we have constrained BRSKI to so far, e.g.:
also systems without certificates, but ... hmm, forgot name, the stuff
we discussed with ACME ?

Maybe just note that these systems have additional pro and cons when
used outside of the realms of BRSKI with IDevID generation, but that
those differences are out of scope of this document. Until they are not,
because someone brings that stuff into BRSKI)

6.  why should i read this

The intro would be helped if it outlined example target readers and what
they would get out of reading the document.

For example; For organizations considering to deploy equipment
using BRSKI, an understanding of the design of the manufacturers design 
and operations IDevID, MASA and voucher can be beneficial or may even be required
to understand security, risk, compliance, trust and reliability aspects
of the pledge devices from that manufacturer.

Not as glamorous, but maybe closer to the truth ?
The autors where overwhelmed of all the different options discussed or
used in the industry, their interactions and implications and just wanted
to start dumping this onto paper in the hope that some sane structuring can evolve
;-)

7. From where we are to BRSKI

I think one mayor reason why to read this are manufacturers that may
have have or plan to have one of the described IDevID designs and now
want to understand what is needed to add support for MASA to their
designs. That could be called out in the introduction, but i think
the IDevID section itself could better distinguish between the
description/judgement that is independent of MASA and then the
new MASA considerations. Maybe structure, put MASA text always at end of
options "When adding/using MASA in this option, the following
applies...".

Cheers

    Toerless

In-Reply-To: <4178.1583770121@localhost>

On Mon, Mar 09, 2020 at 12:08:41PM -0400, Michael Richardson wrote:
> 
> I will post -03 today, after a few other review comments.
> 
> "Xialiang (Frank, Network Standard & Patent Dept)" wrote:
>     > This draft is useful for helping guy to get valuable guidance of
>     > deploying BRSKI MASA service, please see my current comments as below:
> 
> Thank you for your comments.
> 
>     > pg 4:
>     > One way to do the transmission is during a manufacturing during a Bed
>     > of Nails (see [BedOfNails]) or Boundary Scan.
> 
> 
>     > comment:
>     > Can the manufacturer internal scep or similar protocols be the other ways?
> 
> SCEP is the Simple Certificate Enrollment Protocol.
> It variously described as a Verisign/Cisco originated protocol described in
> draft-gutmann-scep-XX.txt and in draft-nourse-scep-XX before that,
> going back to 2000.  Never published, I think because of the problems that it
> has, and because RFC7030 solves those problems.
> In particular, any device/person posessing a valid password can typically
> request any certificate contents.
> 
> Having said that, SCEP could be used in a controlled manufacturing
> environment to do initial enrollment.  My understanding is that the issues
> that make it a problem (and which I think has prevented the IETF from
> publishing it, preferring EST/RFC7030) would not apply in a controlled
> environment like a manufacturer.
> 
> I have added a section matching Laurence's slide 32.
> 
>     > pg 4:
> 
>     > has been started the first time.
> 
>     > comment:
>     > Both in the manufacturing process and in-field provisioning process?
> 
> For on-device private key generation, the device needs to be started at least
> once in the factory, when it is attached to the factory provisioning system.
> After that, some flag needs to be set to prevent any further generation.
> This could be as serious as a blowing a fuse!
> 
> I have clarified this section:
> https://github.com/mcr/masa-operational-considerations/commit/10a12fb406d254dc1172ae5cb2be2f2cc920f709
> 
>     > pg 4:
>     > A serial number for the device can be assigned and placed into a
> 
> 
>     > comment:
>     > Is it appropriate to assign the serial number to device, since device has
>     > already had its own SN?
> 
> This is device has a single serial number.
> The point is that a device may not yet have a serial number, and it is
> possible to assign the serial number during this process.  Or perhaps more to
> the point, the manufacturer step that a serial number is assigned,  is the
> right time to deploy the private key.
> 
> 
>     > pg 5:
>     > Ongoing access to the root-CA is important, but not as critical as
>     > access to the MASA key.
> 
> 
>     > comment:
>     > MASA key is not relevant with the IDevID three-tier PKI
>     > infrastructure. So, does this sentence make sense here?
> 
> This comment is about relative levels of access to the private keys.
> The key that the MASA uses to sign vouchers *needs* to be online.
> The root-CA for the IDevID PKI can be offline, locked in a vault (and guarded
> by Godzilla if you like).
> 
> 
>     > pg 5:
> 
>     > The IDevID certificates have very long (ideally infinite)
>     > validity lifetimes for reasons that [ieee802-1AR] explains, but once
>     > the certificates have been created the intermediate CA has no further
>     > obligations as neither CRLs nor OCSP are appropriate.
> 
>     > comment:
> 
>     > Miss some text here for clarifying how the updated intermediate CAs with
>     > new keypair can still be used to validate the old IDevID which is issued
>     > with the intermediate CA's old keypair. Can the updated intermediate CA
>     > still store and use the old keypair?
> 
>     > And why do you say that the intermediate CA has no further obligations for
>     > its status update once the IDevIDs have been created?
> 
> I have changed the text to clarify that the private key is not needed online
> after the CA has been retired, but that the intermediate CA certificate
> should have infinite/indefinite lifetime.
>   https://github.com/mcr/masa-operational-considerations/commit/07b551d2cad9584f6fbe984cd2ba854461ee7fb3
> 
> 
>     > pg 6:
> 
>     > A plan to escrow the signing keys SHOULD be detailed, and it is
>     > likely that customers will want to review it for high-value products.
> 
> 
>     > comment:
>     > what is the "escrow the signing keys"?
> 
> It means to keep a (secure) copy with a lawyer in case the company goes under.
> https://en.wikipedia.org/wiki/Source_code_escrow
>         Source code escrow is the deposit of the source code of software with
>         a third-party escrow agent. Escrow is typically requested by a party
>         licensing software (the licensee), to ensure maintenance of the software
>         instead of abandonment or orphaning. The software's source code is released
>         to the licensee if the licensor files for bankruptcy or otherwise fails to
>         maintain and update the software as promised in the software license
>         agreement.
> 
> I have changed the text to speak about business continuity planning instead.
> 
>     > pg 7:
> 
>     > In order to avoid locking down a single validation key, a PKI infrastructure is
>     > appropriate.
> 
> 
> 
>     > comment:
> 
>     > A PKI infrastructure for MASA?
> 
> Yes, for the voucher signing key.
> Good cryptographic hygiene would replace the voucher signing key
> periodically.  The PKI infrastructure means that the vouchers could still be
> validated.
> 
>     > pg 7:
> 
>     > a new End-Entity (EE) Certificate with an online
>     > private key, and use that to sign voucher requests. The entity used
>     > to sign [RFC8366] format vouchers does not need to be a certificate
>     > authority.
> 
> 
> 
> 
>     > comment:
>     > Why is it the EE Certificate?
> 
> End-Entity certificates are certificates which are not Certificate
> Authorities (whether root or intermediate).  The voucher does not need to be
> signed by a certificate authority, as the voucher is not a certifiate.
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


-- 
---
tte@cs.fau.de