[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Provisioning, Password Strength (was RE: comments)

Eric, George,

I've been following the password strength debate
with great interest.  While I certainly agree that
strong authentication is important, it is impractical
to expect network devices to perform all the strength
checks themselves.

As I see it, strength checks for static passwords fall
into three types:

 1 - computational checks against the password
     itself (length, character set, upper/lower case)
 2 - comparison checks against static data
     sets (dictionary tests)
 3 - comparison checks against dynamic data
     sets (history checks, username tests)

I would support checks in group 1 being in the document,
and then we can argue about exactly what checks are
minimally necessary.  I would not support checks in
groups 2 or 3 being mandated by the document, although
they could be in there as SHOULD/MAY requirements.

I also agree with Eric's position on central authentication
servers (ACS, or AAA servers as some call them).  They've
been in the document from the beginning, and that requirement
should stay.  However, I think we should be very reluctant to
mandate support for any particular authentication protocol.

...nz (Neal Ziring, TD/C4 NSA)



------------------------------------------------------------



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?




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

For most definitions of "strong", many network devices cannot perform
the neccessary work, store the requisite dictionaries, etc.  If you
are doing remote AAA (RADIUS, etc), then enforce it on the AAA server.
If not, leave the poor router alone.  I can't imagine a 2500 trying to
do password strength checking.

I think poor passwords are OK, as long as they are not well known poor
passwords.  We're not really worried about grinding attacks here, most
network devices protect against that pretty well (delays,
disconnections), but more about passwords that everyone on earth
knows.





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.




gj> Actualy, it sounds like two seperate requirements:

gj>  (1) Enforce the selection of strong passwords.

I'd drop this one.  Policy, a good one, but not a vendor requirement,
or really implementable.  (And it gets subsumed in (2))

gj>  (2) Support ACS servers.

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

(2) SHOULD be universal.  Any enterprise that relies even marginally
upon IP devices will eventually be crushed with the number of obscure
embedded passwords that they have to remember, resulting in a shortage
of sticky notes and poor password control.

I am currently beating on Sun to provide AAA capabilities for their
T3/T4 bricks, and SunFire SC controllers.  I beat on BayTech to
provide AAA for their manageable power strips.  Local passwords are
fine when you can count your humans and your devices on one hand.
Otherwise they're evil.

The cost of putting up a RADIUS server or whatever will pay for itself
the first time you don't spend an hour looking for the magic sticky or
trying to remember how to do password recovery on obscure box X.

ericb