Brian E Carpenter <[email protected]> wrote: >> 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.
I agree, it's a bit similar.
Except that the voucher is a signed entity, and disclosing it causes privacy
issues (people know what you have), rather than being p0wned. It can easily
go on a CDROM or something else you do trust.
A QR code is also possible, assuming your personnel-safety-critical device
has a camera.
[oh. Now I'm thinking about 2001, Space Odyssey. I'm seeing Dave Borman with
a giant QR code tattoed on him, much like we proposed doing with the RSA
algorithm back during the cryptowars of the 1990s ]
{and the issues with USB devices are squarely a problem of GUIs accepting
input devices without validation. It's fixable}
>> 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.
And, worse, I think, it's prone to human error, which is exactly what we want
personnel-safety-critical devices not to suffer from.
>> > 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>.
okay.
It's gonna take a gallon or two of caffeinated beverage.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
