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

[Brian E Carpenter <[e-mail]>]

On 2018-10-03 15:35, Michael Richardson wrote:
> 
> Brian E Carpenter <[e-mail]> 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 masa.vendor.com, 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... statscan.gc.ca 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.

Yes, that sort of solution would work.
 
> 2) you use NETCONF's mechanism with vouchers that you obtain another way, and
>    you place them on USB key/CDROM/QR-code.

You could. But that makes me a bit nervous too. It's not far from
seeing a yellow sticky in the ops room saying "sys pw muggle3scop#"
or whatever. People who want airgap security are very cautious about
USB keys these days.

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

It still doesn't scale.

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

Later, maybe, but to get this draft out of the door I think we can
do a simpler fix. As Christian pointed out, there isn't really
a distinct security analysis, so I think we need to say:
This <text> is the recommencded trust model, based on an on-line
MASA. If you don't like that trust model, here are the alternatives: <text>.

   Brian