Provisioning, Password Strength (was RE: comments)

[George Jones <gmj@pobox.com>]

On Tue, 17 Jun 2003, Chris Lonvick wrote:

> > Actually, per ericb's suggestion, I think a better idea is to have
> > things shipped unconfigured (no passwords, etc.) and simply not allow
> > a service/account/whatever to be used unless the user explicitly
> > configures it.
>
> I like that approach as well.  It may be good to differentiate between
> provisioning and managing as well.  There are a lot of problems associated
> with provisioning which are similar to configuration but are much more
> difficult to address.

Examples ?   Any cases where I've got things mixed now ?

> > See above.
> >
> > >  The device should provide the capability
> > > - to enforce 'strong' password selection.
> >
> > Care to provide a definition of "strong" ?
>
> Is this a recommendation for the device or for a device within the
> >system?

Don't care.  If people are setting passwords, they should be strong.
More accuratly, there should be the option of requiring them
to be strong...if someone has a policy that says "thou shalt have
weak passwords" they should be able to have them.

> It would be difficult for a small hub to be able to review contained
> password for "strenth" (whatever that definition may become) but it is
> relatively easy for an Access Control Server (ACS - i.e. a RADIUS server)
> to perform such checks.  I'd recommend going with the association made in
> the T1M1.5 document which allows that check to either be performed on the
> device, or within the system.

Actualy, it sounds like two seperate requirements:

  (1) Enforce the selection of strong passwords.

  (2) Support ACS servers.

(2) may be part of the implementation of (1).   (2) may not be univeral.
(1) should probabably be universal.

I could still use a definition of "strong".

Thanks,
---George