RE: comments

[Chris Lonvick <clonvick@cisco.com>]

Hi,

On Tue, 17 Jun 2003, George Jones wrote:

> On Tue, 17 Jun 2003, Budd, Fred wrote:
>
> > There are a few other knobs and information requirements centered
> > around this point that I'd like to see. The wording is rough but
> > bear with me - I've only had a couple of cups of java at this
> > point. Will flesh the thoughts out later if noone beats me to it.  -
> > It must be possible to change all initial passwords or similarly
> > fixed authentication information (SNMP community strings, etc.) from
> > the factory default.
>
> 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.  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.

>
> > - The vendor must provide a documented list of all management
> > - passwords or similar authentication material, management accounts,
> > - and management interfaces that the listed authentication works
> > - with. (community strings, backdoor maintenance accounts, hidden
> > - system accounts, etc.)
>
>
> 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?
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.

>
>  > > Also, and this is a
> > - syntactical nitpick, the examples should be consistent with the
> > - requirement. Taking the example below, using "standard management
> > - protocol" and "externally accessible" does suggest that it is
> > - perfectly fine to allow default passwords for management access
> > - with non-standard implementations, proprietary protocols, or
> > - supposedly internal interfaces which just happen to be made
> > - externally accessible; even though those scenarios wouldn't meet
> > - the explicit requirement. Is the intent that the initial
> > - configuration must occur through the OoB management interface(s)?
>
> That was the thinking, but I think this need to be revisited.
>
> > - Or is the draft going to suggest a trusted/untrusted
> > - (internal/external) philosophy?
>
> It was assumed that the OoB would be "internal"/more trusted.
>
> >  I ask simply because I've talked
> > - to quite a few vendors who fully expected a firewall type device
> > - to front their equipment and thus didn't give much thought to
> > - management access controls.  Therefore, they never anticipated the
> > - management protocols being available to external parties.
>
> Do they state that ?

I've heard this from Telco people.

Later,
Chris