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

RE: comments



So every device must be initially configured through a serial port or similar mechanism? Seems a bit contradictory since one of the examples for the OoB interface (2.1.1) could be a [dedicated/isolated] Ethernet port. Realistically, one of the initial device configuration options could be put the device on RFC 1918 subnet x, telnet to a.b.c.d and use blah:blah when prompted for account and password. It would probably also be beneficial to more explicitly state what remote access actually means in this context. (Again, default/no passwords on the console port?)

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.  
- 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.)
- The device should provide the capability to enforce 'strong' password selection.

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)? Or is the draft going to suggest a trusted/untrusted (internal/external) philosophy? 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.

-Fred Budd 

-----Original Message-----
From: Dan Hollis [mailto:goemon@anime.net]
Sent: Monday, June 16, 2003 6:00 PM
To: Smith, Donald
Cc: George M. Jones; opsec@ops.ietf.org
Subject: RE: comments

On Mon, 16 Jun 2003, Smith, Donald wrote:
> > On Mon, 16 Jun 2003, George M. Jones wrote:
> > > Requirement:
> > > The device MUST NOT allow any remote access for management without
> > > explicit configuration of authenticaiton and authorization.
> > > Example:
> > > It should not be possible to use a well know default 
> > password to remotely
> > > manage a newly installed device using standard management protocols
> > > (telnet, SNMP, SSH ...) manage a newly installed device on any externally acessable interface.
> What I am worried about is someone moving telnet to port 53 and saying its non standard
> so it passes are requirement. 

It wouldnt pass the requirement stating explicit configuration of 
authentication and authorization.

-Dan
-- 
[-] Omae no subete no kichi wa ore no mono da. [-]