Re: [spam score 5/10 -pobox] draft-jones-opsec-01.txt comments

["Joel N. Weber II" <ietf-opsec@joelweber.com>]

> > What I was thinking about there was more what sort of infrastructure
> > you could afford to rely on for the different classes of users.  There
> > are some authentication technologies out there which simply cannot
> > work when the only thing on the device that's working is an ASCII
> > console port.  Yet some of those technologies that require some more
> > infrastructure are more usable/scalable in a large environment.
>
> e.g. biometrics, remote auth-servers (no IP to reach them), others ?

Yeah.  I was mostly thinking of remote authentication servers
(Kerberos, RADIUS, on line verification that a certificate hasn't been
revoked, etc), though.  I don't know anything about how biometrics
work wrt interfacing to computers/network devices, so I can't comment
on that.

An interesting question is whether it's ever appropriate to rely on a
remote auth server if the server lives on the management network side
of your universe, if you have a management network.  If there's an
auth server in every POP with a local copy of the database, or perhaps
two such servers, can you make a reasonable argument that you
absolutely must have a strictly local authentication method?

(Of course, the inevitable problem with that is that one year, someone
will decide to renumber one of the auth servers, and forget to update
some device.  That device will keep working, because the other auth
server is there, until two years later that auth server that the
device was still talking to finally randomly breaks...)

> I think what's missing is something that specifies a local enable
> password (in IOS terms) or root user (unix) that will *always*
> work, network or no, special devices or no...that and possibly
> "password recovery" functionality with physical access.

yeah, something like that.

You always need to have a way to recover if the password is long lost,
but maybe that doesn't need to imply giving you a copy of the
configuration that had been on the device.

I suspect we want to require that there always be a way to get full
access to change the configuration on the device on the OOB management
port without rebooting it, and without the device consulting any other
devices to determine authentication.