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

[<nick.edwards@bt.com>]

The majority of biometrics devices have proprietary interfaces to computer hardware. These days, most are USB, but the devices require specific drivers in general. Although there are initiatives for creating standard interfaces, e.g. BioAPI, BAPI, these are normally middleware layers that reside on a PC and thus the communications with the hardware remains proprietary.

Regards

Nick Edwards



Dr Nick Edwards
Security Technologies Research
BT Exact

e-mail: nick.edwards@bt.com
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000 

This electronic message contains information from British Telecommunications plc which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the number or address above) immediately. 

-----Original Message-----
From: Joel N. Weber II [mailto:ietf-opsec@joelweber.com]
Sent: 23 October 2003 19:06
To: gmj@pobox.com
Cc: Joel N. Weber II; opsec@ops.ietf.org
Subject: Re: [spam score 5/10 -pobox] draft-jones-opsec-01.txt comments


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