On 2018-10-03 15:35, Michael Richardson wrote:
>
> Brian E Carpenter <brian.e.carpen...@gmail.com> 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
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
