Re: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

Michael Richardson <> Wed, 03 October 2018 02:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24007131126; Tue, 2 Oct 2018 19:35:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yoPV4Z8nkaFP; Tue, 2 Oct 2018 19:35:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFE54131181; Tue, 2 Oct 2018 19:35:26 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id A5EDA20090; Tue, 2 Oct 2018 22:35:20 -0400 (EDT)
Received: by (Postfix, from userid 179) id 6CEDB230F; Tue, 2 Oct 2018 22:35:21 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id 68F86230C; Tue, 2 Oct 2018 22:35:21 -0400 (EDT)
From: Michael Richardson <>
To: Brian E Carpenter <>
cc:, Security Directorate <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <2555.1538506845@localhost> <> <23133.1538520783@localhost> <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Tue, 02 Oct 2018 22:35:21 -0400
Message-ID: <10809.1538534121@localhost>
Archived-At: <>
Subject: Re: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Oct 2018 02:35:29 -0000

Brian E Carpenter <> wrote:
    > I'm still gnawing on my original bone: if I was running a highly
    > secure, personnel-safety-critical network, like the particle
    > accelerator control network I used to run for a living, I *would not*
    > allow it to rely on, and it would be physically
    > impossible to do so because there would be no physical link anyway. I
    > would get my vouchers some other way. This is not light bulbs either.

So possibilities that I see:

1) you run a half-mind Registrar that is on the secure side of your air-gap, and it has
   a USB interface (or 9-track tape drive... used to run
   unidirectional UUCP over 9-track tapes walked across the machine room air-gap)
   on which it can place voucher requests, and receive vouchers from
   other-half-mind Registrar.

   This lets you use nonced vouchers, potentially with expiry dates.
   Maybe very long expiry dates.  Or maybe your personnel-safety-critical
   equipment has a best-before date, and so it's acceptable for you to have
   vouchers only until that date.

   Also recall that we permit the Registrar to ask for, and get, voucher
   renewals at any time, so the connected ("other-half-mind") Registrar could
   always keep a live set of vouchers.

2) you use NETCONF's mechanism with vouchers that you obtain another way, and
   you place them on USB key/CDROM/QR-code.

3) you continue to configure such a network with craft-serial console,
   initiating the EST connection via some other credential.

    > I believe this can be fixed by clearer scoping of the document, and by
    > renaming the "lower security" section as "alternative trust models" or
    > something.

I accept that the document could have better text here.
At one point we discussed an operational considerations document.
Is that really what you are asking for?

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-