Response to opsec issues raised by Russ White

[George Jones <gmj@pobox.com>]

rw> "profiles",
rw>
rw> The comma should be before the end quote. It's a nit, I know.... :-)

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

  http://webster.commnet.edu/grammar/marks/quotation.htm.

Lacking an RFC stating IETF position on this grave issue (:-)), I will follow
the usage in rfc2119 and place commas outside the quotes (xml2rfc also does
this in references).

For an amusing explanation of the seeming completely illogical American use
of commas and quotes, see:

  http://webster.commnet.edu/grammar/marks/quotation.htm#footnote


rw>
rw> --
rw>
rw> [RFC2196]. [1].
rw>
rw> I'm not certain why you went to number references? The descriptive
rw> references are much better.

<waffle>
Because other feedback (from Pekka Savola) said it was better/more standard.
I'm ambivalent.   I sort of agree with you that the symbolic refs are more
intuitive.

I've switched it back.   If someone (the RFC editor ?) tells me this is wrong,
I'll waffle further.
</waffle>


rw>
rw> --
rw>
rw>   The following are explicitly out of scope:
rw>
rw> Kill the commas at the end of every bullet here.

I think, based on these:

  http://englishplus.com/grammar/00000096.htm
  http://www.esrc.ac.uk/commstoolkit/branding/editorial.asp#bull

that the commas are correct, but that the list items should have
lower-case initial letters.  If anybodies got a "normative" grammar
and punctuation reference, I'd be glad to consult that (he says
as he ducks, anticipating holy wars over British, American and other
English usage).

I've made a pass over all the bulleted lists to try to standardi[sz]e
the usage.

rw>
rw> --
rw>
rw> In order to assist in classification, the Appendix A defines several
rw>
rw> "the Appendix A" should be "Appendix A."

Fixed.

rw>
rw> --
rw>
rw>    It is anticipated that this document will be used for the following
rw>    purposes:
rw>
rw> The bullets are missing in this list?

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.

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

rw>
rw> --
rw>
rw> Examples include TLS [RFC2246] [9] and IPsec [RFC2401]. [10].
rw>
rw> Here, I would use [IPSEC] and [TLS], rather than number references.

Number refs are gone.  Still citing by RFC#.

rw>
rw> --
rw>
rw> Spoofed packets are often "bogons" or "martians".
rw>
rw> Didn't you define a bogon as an address above, and a martian as a
rw> packet? A packet couldn't be a bogon, could it?

I refined the definition of "bogon":

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

rw>
rw> --
rw>
rw> 2.2.1 and 2.2.3 seem to overlap a good bit--are both of them really needed?


Yes.   One says the crypto should be subject to open review.
The other says the protocols should be subject to open review.

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

rw>
rw> --
rw>
rw> 2.2.5 Management Functions Should Have Increased Priority
rw>
rw> This section talks about management functions, but then continues
rw> with an example of control plane prioritization. These are two
rw> different things, I think (?), and should probably be treated
rw> separately.

There has been some blurring.  What matters in the end is security
of anything that changes the state or configuration of the device.
I've added the following definition which describes the usage of
the term management:

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.

rw>
rw> --
rw>
rw>    In both cases the security of in-band communications beyond the
rw>    management interface (e.g. console port, management network
rw>    interface) is assumed.
rw>
rw>
rw> I would make the following list a bulleted list, or refer to the
rw> other sections discussing assumptions about security on out of band
rw> management mechanisms (if there are any other sections). If there
rw> isn't another section with this information, it might be better
rw> to make it a separate section, so you can cover the material
rw> completely and then refer to it throughout.

Better ?

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.

rw>
rw> --
rw>
rw> Problems in any of these areas could have negative
rw> security impact, particularly in situations where the console must
rw> be used to quickly respond to incidents.
rw>
rw> "a negative security impact," or "negative security impacts."

Fixed.  s/impact/impacts/

rw>
rw> --
rw>
rw>       There MUST be a method defined and published for returning the
rw>       console communication parameters to their default settings.   This
rw>       method must not require the current settings to be known.
rw>
rw> From the console? If you don't know the communication parameters, you
rw> can't connect to the console to find out what the communication
rw> parameters are to connect to the console, right? Even if you use a
rw> special character set, you still have to be able to read the output,
rw> and you can't do that unless you know the communication parameters.

In example:

  s/or a predefined character sequence//

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.

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


rw>
rw> --
rw>
rw> 2.7.5 Support Route Filtering
rw>
rw>    Requirement.
rw>
rw>       The device MUST provide a means to filter routing updates for all
rw>       protocols to be used to exchange external routing information.
rw>
rw> "protocols to be used to exchange...." should be "protocols used to
rw> exchange...."

OK.

rw>
rw> --
rw>
rw> 2.14 Security Features Must Not Cause Operational Problems
rw>
rw> I don't think a vendor can promise this, no matter how you put it.
rw>
rw> --

Dropped from a MUST to a SHOULD and added

04>   Warnings.
04>
04>      Determination of compliance with this requirement involves a level
04>      of judgment.  What is "severe"?  Certainly crashing is severe, but
04>      what about a %5 loss in throughput when logging is enabled?  It
04>      should also be noted that there may be unavoidable physical
04>      limitations such as the total capacity of a link.

Updated draft @

  http://www.port111.com/opsec/draft-jones-opsec-04-working.txt

Updated htmlized diffs @

  http://www.port111.com/opsec/draft-jones-opsec-03-to-04-working.html
  http://www.port111.com/opsec/draft-jones-opsec-03bis-to-04-working.html

Thanks,
---George Jones