[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [spam score 5/10 -pobox] draft-jones-opsec-01.txt comments
Nick Edwards said:
> 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.
Thanks.
Joel Webber said:
>
> -----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
>
> 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?
Sounds like a policy/architecture question. What we want is mechanism
to support such choices.
> > 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,
I'll add soemting like
The device SHOULD support a mechanism to [reset local priviliged
paswords]. This MUST only be possible [with previously established
privilaged level access] or physical access.
I can see policy that says "fail closed/fry the eproms on the third
failed attempt"...but I think it would be reasonable (even BCP) for
most environemnts to say something like
The device SHOULD support a simple local authentication mechanism
with no external depenancies that allows full managent and
configuration access.
The following in combination start to get at this.
2.12.6 Support Local User Authentication . . . . . . . . . . . . 40
2.12.13 Ability to Define Privilege Levels . . . . . . . . . . . . 44
2.12.14 Ability to Assign Privilege Levels to Users . . . . . . . 44
2.12.15 Default Privilege Level Must Be Read Only . . . . . . . . 45
2.12.16 Change in Privilege Levels Requires Re-Authentication . . 45
I'll review and see if it should be made more explicit.
> 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,
without rebooting ?
> and without the device consulting any other
> devices to determine authentication.
Yes. I'll review.
Thanks,
---george