[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