RE: Response to OPS directorate comments from Dan Romascanu

["Smith, Donald" <Donald.Smith@qwest.com>]

My comments will be marked djs>

-----Original Message-----
From: owner-opsec@psg.com
To: opsec@ops.ietf.org
Sent: 2/21/2004 8:00 PM
Subject: Response to OPS directorate comments from Dan Romascanu

dr> ----------------
dr> comments from Dan Romascanu
dr>
dr> Here are some of my reservations:
dr>
dr> 1. Section 1.7
dr>
dr>
dr>   Basis For Testing and Certification. As a  basis for testing and
dr>       certification of security features of networked products.
dr>
dr> I would be reluctant to include this use. As a BCP and non-normative
dr> document, I fail to see how this can be a basis for
dr> certification. Some of our customers are taking very seriously
dr> certification of security, and if IETF is to issue a normative
dr> reference for such an activity, we need a more serious (and
normative)
dr> document.

See

   [I-D.ietf-bmwg-acc-bench-framework]
              Poretsky, S., "Framework for Accelerated Stress
              Benchmarking", draft-ietf-bmwg-acc-bench-framework-00
              (work in progress), October 2003.

For a very good start.

This doc's original use was to take new gear into the lab and beat on
it as part of a testing and cerfitication process.  I believe it still
poses the relevent questsion (can it do centralized auth, can it log,
can it filter.... ?).  FWIW there were companion docs for testing
process, tools used, etc.  This doc was (and still is) the
requirements layer.

dr>
dr> 2. Use of term 'password'
dr>
dr> This document takes a very odd approach for the use of term
password,
dr> especially for a security document. It starts by claiming in Section
dr> 1.8 that 'password' will be used in a very broad way, kind of an
alias
dr> for 'security token'. However, this is not consistently followed and
dr> almost all other instances of 'password' in the document refer to
the
dr> old good interpretation that we all knew. On the other hand, other
dr> types of 'passwords' like SNMP community strings get special
treatment
dr> in some sections.

Right.  That was a vestage of an earlier attpent at being overly
general.  I've deleted the definition.

dr>
dr> 3. Requirement 2.5.3 - If this requirement is to be followed for
SNMP,
dr>    any remote discovery or remote operation for an SNMP managed
device
dr>    would be impossible without the presence of a on-site operator to
dr>    configure locally SNMP through some local craft interface. I do
not
dr>    think that this is BCP - at least not for some classes of
networks
dr>    and devices.

djs> From a carrier point of view we don't allow unconfigured systems into production. There is 
djs> no need for autodiscovery via snmp. In an office or small enterprise enviroment I can see djs> potential need for it. But with the nearly constant scanning for various default passwords 
djs> it is possible a system will be compromised prior to autodiscovery.

Sigh.  You're right.  I will, reluctently, remove that.

This was a pure security best practice.  One of the first rules of
securing a new device is to turn off everything you don't need.  From
a pure securtiy standpoint, it make sense to start there and turn on
ony the things you need.

As long as the previous two

   2.5.1   Ability to Identify All Listening Services
   2.5.2   Ability to Disable Any and All Services

are there, this one is a very-nice-to-have-but-not-essential-enough-
to-break-functionality requirement.  Sigh.  Deleting....

dr> 4. Same about requirement 2.12.9

This one's (no default passwords) a bit tougher.  I see your point.
Again, this is probably more a best-practice in pure security terms.
But go type "default passwords" in to google and see what you get.
It's bad.   See recent coments on the opsec mailing list
(opsec@ops.ietf.org, majordomo, archvies...).  Many people
have had BAD experiences a a result of default passwords.
For now, I'm going to leave this one.

dr> 5. It is odd that while talking about SNMP in the context of secure
dr>    management, the document does not mention the need to activate
the
dr>    auth and priv modes, and the need to use access control with
dr>    different rights for different sections of the MIB. Maybe if the
dr>    authors were aware about how these can be used, their concerns
dr>    reflected in requirements 2.5.3 and 2.12.9 would have been
dr>    alleviated.

I admit I don't have a lot of depth on SNMP. Give me pointers or better
still, suggested text.  I am trying to be editor, not author.

I do think that "no default passwords" and "listening services off by
default" (now deleted) are importnat in genreal, not just as reletes
to SNMP.

dr> 6. The way the first paragraph in Section 2.2 is written it makes a
dr>    strong case against using in-band management. I would observe
that
dr>    this is far from being a BCP.

True, for all but the largest (see scope) or most paranoid networks.

dr>    I suggest that this paragraph be
dr>    re-formulated. While showing up the increased risks and
mentioning
dr>    the attacks related to usage of in-band management, in should
dr>    emphasize that there are means to defend, hence the requirements
in
dr>    the following sections.

Added the following:

04>   There are many situations where in-band management makes sense, is
04>   used, and/or is the only option. The following requirements are
04>   meant to provide means of securing in-band management traffic.

dr>
dr> 7. The 'Warning' section in 2.3.1 is a strong argument in favor of
dr>    RS-232, but has little to do with Security.

djs> This stems for the fact that nearly every carrier (isp) is currently using rs232 terminal 
djs> servers when other access is unavailable. The cost to replace that infrastructor is large. djs> Managment availablity could 
djs> be affected if a different standard was implemented by the vendors.



I could argue for the securtiy impact of every one of the attributes
listed.   When there's a problem, the console interface has to work,
work easily, and work NOW.   RS232 does that, precicely for the
reasons listed.    I had moved away from RS232 but was beaten
by opererators into adding it back in.  That list is good benchmark
to judge any replacement technology by.

I've moved it from "Warning" to "Examples" (warning didn't make
sense).

I've added the following:

04>      While other interfaces may be supplied, the properties listed
04>      above should be considered. Interfaces not having these
04>      properties may present challenges in terms of ease of use,
04>      integration or adoption.  Problems in any of these areas could
04>      have negative security impact, particularly in situations where
the
04>      console must be used to quickly respond to incidents.

dr> 8. Sections 2.4.1 to 2.4.4 would belong to a 'CLI Requirements'
dr>    document, but why should they be part of a 'Operational
dr>    Requirements for Security' BCP? I would also observe that there
is
dr>    no 'standard CLI' - not in IETF at least - at this point in time.

See the justificaiton for each one to see why they are listed in a
secruty document.  THe list contains features that are securtiy
related benefits of having a CLI.

I had moved away from the CLI in earlier drafts, but was convinced to
put it back in (discussions are mostly in the opsec archive I think).
I've tried to leave room for netconf, etc.   See definitions, intro 2.4

Also, without specifying the details or attempting to standardize it,
I believe that command line interfaces are very clearly a widesperead
current practice and fairly well understood.   "best" may be arguable.


djs> With a modem and a CLI. An operator can dial in to a terminal server. Cut and paste the 
djs> configuration on to the router and have it back in working state in less then a minute.
djs> If the operator is forced a series of curses based menus or required to run a vt100 htlm 
djs> interface it will take MUCH longer.

dr> 9. However, if we are dealing with proprietary interfaces, why are
dr>    requirements for 'Web interfaces' - quite widely used in device
and
dr>    server management almost totally absent?

IIRC, I tried to move to a more generic (i.e. not "CLI") description
of secrutiy managment requrements, explicitly listing HTTP as as
an option, but was shot down in the attempt to argue that they
were equivilant.   Again, discussion in the opsec list I think.

dr> Please do not interpret this as a fully negative view of the
dr> document. Quite the opposite, I find it very valuable, and there are
dr> many useful and accurate items.

Thanks.  The comments help.

dr> Most of my reservations are related to
dr> the management aspects, and to the fact that it provides
requirements
dr> which are not aligned with a BCP. Maybe dropping 'BCP' from the
title,
dr> and making the document just an Informational at this point in time
dr> would be better.

I'm just collecting/editing useful ideas (trying anyhow).  Will go
whichever way people think it would be most useful.

---George Jones