Re: Response to opsec issues raised by Russ White

[Russ White <ruwhite@cisco.com>]

> Wow.  Now we're down to American vs. British usage of the English
> language:

Hmmm.... I didn't realize there was a difference. :-)

> Try this:
>
> 04> 1.7 Intended Use
> 04>
> 04>    It is anticipated that the requirements in this document will be used
> 04>    for the following purposes:
> 04>
> 04>    o  as a checklist when evaluating networked products,
> 04>
> 04>    o  to create profiles of different subsets of the requirements which
> 04>       describe the needs of different devices, organizations, and
> 04>       operating environments,
> 04>
> 04>    o  to assist operators in clearly communicating their security
> 04>       requirements,
> 04>
> 04>    o  as high level guidance for the creation of detailed test plans.

This is fine....

> rw>    CLI.
> rw>
> rw>       Several requirements refer to a Command Line Interface (CLI).
> rw>       While this refers at present to a classic text oriented command
> rw>       interface, it is not intended to preclude other mechanisms which
> rw>       may meet all the requirements that reference "CLI".
> rw>
> rw> I would replace this throughout with "user interface," or "UI."
> rw> There's no reason to specify CLI, and then define it as UI. :-)
>
> This one has been back and forth several times.  I tried to abstract it,
> but I think clarity was lost, so it came back to CLI with caveats that
> other mechanisms that met the same requirements would be acceptable.
> The CLI is a well known beast, even if ill defined.  When you say "CLI"
> people know what you're talking about.  Saying "user interface with the
> following 10 qualities" does not have the same clarity.

Well, but when you say "CLI," you mean a command line interface. This
draft, then requires all devices to have a command line interface--a gui,
or any other interface, isn't allowed, unless a CLI is also available. Is
that the intent?

> 04>   Bogon.
> 04>
> 04>      A "Bogon" (plural: "bogons") is a packet with a IP source address
> 04>      in an address block not yet allocated by IANA or the Regional
> 04>      Internet Registries (ARIN, RIPE, APNIC...)  as well as all
> 04>      addresses reserved for private or special use by RFCs.  See
> 04>      [RFC3330] and [RFC1918].

This is fine....

> rw> Should you refer to the idr draft about choosing good MD5 keys at some point in the 2.2.3 area, maybe?
>
> I-D.orman-public-key-lengths ?
>
> That's about key lengths and strength, and hence cited in 2.2.2 which is
> about cryptographic strength.  2.2.3 is about open review of protocols.

I was thinking about 3562. I don't know if that would fit in here anyplace,
but it might be a useful reference (?).

> 04>   Management.
> 04>
> 04>      This document uses a broad definition of the term "management".
> 04>      In this document, "management" refers to any authorized
> 04>      interaction with the device intended to change its operational
> 04>      state or configuration. Data/Forwarding plane functions (e.g. the
> 04>      transit of customer traffic) is not considered management.
> 04>      Control plane functions such as routing, signaling and link
> 04>      management protocols and management plane functions such as remote
> 04>      access, configuration and authentication are considered to be
> 04>      management.
>
> http://www.laurelnetworks.com/products/literature/security.pdf lays
> out the problem pretty well.

Okay, this is fine....

> 04>   The following assumptions are made about out-of-band management:
> 04>
> 04>   o  The out-of-band management network is secure.
> 04>
> 04>   o  Communications beyond the management interface (e.g. console port,
> 04>      management network interface) is secure.
> 04>
> 04>   o  There is no need for encryption of communication on out-of-band
> 04>      management interfaces, e.g. on a serial connection between a
> 04>      terminal server and a device's console port.
> 04>
> 04>   o  Security measures are in place to prevent unauthorized physical
> 04>      access.
> 04>
> 04>   Even if these assumptions hold it would be wise, as an application of
> 04>   defense-in-depth, to apply the in-band requirements (e.g. encryption)
> 04>   to out-of-band interfaces.

This is fine....

> The example section now reads:
>
> 04> One method might be to send a break on a serial line.  Another might
> 04> involve physical action such as setting a jumper and/or power cycling
> 04> the device.

This is fine....

> rw> 2.4 Configuration and Management Interface Requirements
> rw>
> rw> I think you need better justification for this section than what
> rw> you've given here. This section is more of a wish list of what the UI
> rw> should support, and there's seems to be little justification given
> rw> for why these things make a network more secure (?).
>
> I disagree.   I just re-read all the justification sections in 2.4.x
> and I think each one of them gives adequate security-related rational
> for the individual requirement.   Show me which ones you think are weak
> on security rational ?

Well, why is it important that the interface be scriptable or programmatic?
I can see why it is from an operational perspective, but from a security
perspective? Wouldn't these sorts of things be better in a generic
"suggestions to vendors" draft, and then referenced here, since they are
more generic than security?

Thanks!

:-)

Russ


__________________________________
riw@cisco.com CCIE <>< Grace Alone