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