RE: comments

["Budd, Fred" <Fred.Budd@wcg.com>]

What is the thought with regards to encompassing concepts from other
standards or recommendations? (T1M1.5, common criteria profiles,
federal IA, etc.) Should they be addressed in the document or included
by reference?

> > On Tue, 17 Jun 2003, George Jones 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.

Requiring every management authenticator to be explicitly set before
use works for me (and parallels T1M1.5), as long as the device:
- Doesn't allow null local authenticators. If a subset of users don't
change default passwords before deploying gear then there is subset
who will just hit enter when prompted for a password.
- Must prompt for a new initial authenticator (e.g. password) on all
interactive interfaces, if local authenticators are enabled, until
one is set through a non-IP OoB connection or from a local IP address.
- Must prohibit remote inline management access until the
authenticator has been set.  
- Must not exhibit different behavior for protocols enabled out of the
box and those that must be manually turned on.

> 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.  I'd suggest
> putting those off for now and complete the basic structure of the
> document with the best recommendations that can be made.  A future
> document may then attempt to cover provisioning.

Agreed to an extent. My understanding is that this document does
intend to address provisioning concerns, limited to enumerating the
tunable control features that are desired and the initial setting for
same.

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

Strong is subjective and depends on the operational context (account
lockout after x failures, history checking, forced change intervals).
Probably should have followed T1M1.5 and used complex. What I was
thinking was that the device needed tunable mechanisms to enforce
password (or any other static authenticator) complexity. A minimal set
of characteristics would be mandatory minimums on length and included
alpha/numeric/special characters.

The requirement could be met using a central authentication server.
However, if the document intends to address requirements for
deployments that may not have such a system, or don't require it, then
this should be enforced locally.  Actually, there should be a minimum
set of local controls required regardless. If the procedural elements
(provisioning and ongoing management) are abstracted then all
applicable deployment environments should be addressed or explicitly
defined as out of scope.

> > >  I ask simply because I've talked to quite a few vendors who
> > > fully expected a firewall type device to front their equipment
> > Do they state that ?

Yes. And in a majority of the cases the devices fully supported and
sometimes didn't allow disabling of inband management. 

-Fred Budd