Re: 03bis draft review

[George Jones <gmj@pobox.com>]

On Mon, 15 Mar 2004, Pekka Savola wrote:

> substantial
> -----------
>
>      The following are some ALGORITHMS that satisfy the requirement at
>       the time of writing: AES [FIPS.197], and 3DES [ANSI.X9-52.1998]
>       for applications requiring symmetric encryption; RSA [RFC3447] and
>       Diffie-Hellman [PKCS.3.1993], [RFC2631] for applications requiring
>       key exchange; HMAC [RFC2401] with SHA-1 [RFC3174] for applications
>       requiring message verification.
>
> ==> maybe it would be useful to state that MD5 (as it's commonly used
> -- e.g., the BGP MD5 checksums would not fulfill the requirements if
> so) is (not) sufficient (and maybe why).  Or is this taking it too
> far?

smb and friends said it better than I could in 3631, so:

04>     Per [3] "Simple keyed hashes based on MD5 [17], such as that
04>     used in the BGP session security mechanism [18], are especially
04>     to be avoided in new protocols, given the hints of weakness in
04>     MD5".

>
> 2.2.3 Use Cryptography in Protocols Subject To Open Review
>
> ==> I don't quite understand the title, so maybe a rewording might not hurt,
> e.g. "Cryptographic Protocols Subject to Open Review"

Better ?

04> 2.2.3 Use Protocols Subject To Open Review For Management

>
> 2.4.7 Support Remote Configuration Restore
>
>    Requirement.
>
>       The device MUST provide a means to restore a configuration that
>       was saved as described in Section 2.4.6. The system MUST be
>       restored to its operational state at the time the configuration
>       was saved.
>
> ==> how does this relate to 2.4.6 where passwords in the configs MAY
> be excluded from the saved config?  I.e., how would such excluded
> config be restored in particular wrt. passwords and other info (e.g.,
> BGP MD5 secrets which are typically excluded but critical to restore
> the box)?  Maybe need a bit rewording, or at least a note in
> "Warnings" section if nothing else...

Paragraph added to warning:

04>      Note that if passwords or other sensitive information is
04>      excluded from the saved copy of the configuration, as allowed by
04>      Section 2.1.1, then the restore may not be complete.  The
04>      operator may have to set new passwords or supply other
04>      information that was not saved.

> 2.5.1 Ability to Identify All Listening Services
>
>    Requirement.
>
>       The vendor MUST:
>
>       *  Display the interfaces on which each service is listening.
>
> ==> services aren't bound to interfaces, but IP addresses (which may in turn
> be bound to interfaces, but their access might not be limited to such).. so
> this is a bit non-sensical requirement.  Maybe must display which IP
> addresses the service is bound to?

Better ?

04>     *  Display the addresses to which each service is bound.
04>     *  Display the interfaces to which each address is bound.

04>   Examples.
04>
04>      If the device is listening for SNMP traffic from any source
04>      directed to the IP addresses of any of its local interfaces,
04>      then this requirement could be met by the provision of a command
04>      which displays that fact.

>  (Note that that is not commonly
> supported either, I think -- but at least one vendor does.)

Maybe not...but this is not a high bar ("netstat -an","lsof -i", and
"ifconfig" in Unix terms) and has high utility from a security
standpoint.

> ==> this may also require small finetuning of text in section 2.5.3,

OK.  Tweeked.

04>   Requirement.
04>                                                                                               04>      The device MUST provide a means for the user to specify the
04>      bindings used for all listening services.  It MUST support
04>      binding to any address or netblock associated with any interface
04>      local to the device. This must include addresses bound to
04>      physical or non-physical (e.g. loopback) interfaces.


> "Ability to Control Service Bindings for Listening Services".
>
>       *  which network element received the packet (interface, MAC
>          address or other layer 2 information that identifies the
>          previous hop source of the packet)
>
> ==> related to the previous point, this is good in principle, but might not
> give sufficient advice (or sufficiently tight leash to the operators :), as
> interface is not sufficient in e.g. Ethernet media.

I think it is sufficient even in the ethernet case ..given a flood of
spoofed addresses, if you can find out which interface packets came
in on, you can do hop-by-hop tracing if necessary.

> Maybe some notion of
> PtP vs non-PtP interface requirements needs to go in here
> somewhere..

Do you have counter examples ?  Wording ?

>
>    Examples.
>
>       This requirement implies that it is possible to filter based on
>       TCP or UDP port numbers, TCP flags such as SYN, ACK and RST bits,
>       and ICMP type and code fields. One common example is to reject
>       "inbound" TCP connection attempts (TCP, SYN bit set).
>
> ==> This "established/initial" -check is not actually as simple as that, and there
> is variance about this with the vendors, so this text may need rewording (or
> picking a different example).
>
> That is, some check, "SYN & !ACK" for initial, and
> "ACK | RST" for established.  Others check for "SYN & !(ACK|FIN|RST)" for
> initial.  (The difference is practically that one approach allows SYN+RST
> christmas packets in through the established rule, and the other does not.)  I had a long
> rant amount that with a few vendors a year or two ago but I don't remember
> the exact details.

Better ?

04>      "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit
04>      clear or SYN bit set+ACK,FIN and RST bits clear).  Another
04>      common

>
> 2.12.3 Support Simultaneous Connections
>
>    Requirement.
>
>       The device SHOULD support multiple simultaneous connections by
>       distinct users, possibly at different authorization levels.
>
> ==> should the SHOULD be a MUST?  I think this is pretty important, at
> least, and AFAIK, pretty widely implemented as well..

Good point.   Especially important given the scope ("I'm sorry, you
can't log in now to fix the security problem, someone else logged in
to fix a performance issue 3 weeks ago and forgot to disconnect...")

> 3.2 Document Service Defaults
>
>    Requirement.
>
>       The vendor MUST provide a list of the default state of all
>       services.
>
> ==> has this been done in practice?  I sure would love to get this info, but
> haven't seen it myself at least...

Again, this may not be universal, but it's not a high bar:

  - log into box with default config
  - list running + non-runing services
  - include output in system docs

> editorial
> ---------
>
>    o  Physical security,
>
> ==> remote "," (last bullet item)

fixed.

>
>      The following are some ALGORITHMS that satisfy the requirement at
>
> ==> any reason why you're writing ALGORITHMS in a few places in
> all-caps?

lowercased.

>       If cryptography is used to meet the secure management channels
>       requirements, then the key lengths and algorithms SHOULD be
>
> ==> s/channels/channel/ ?

fixed.

>
>       Protocols that have not been subjected to widespread, extended
>       public/peer review are more likely to have undiscovered weaknesses
>       or flaws than open standards and publicly reviewed protocols
>
> ==> add dot at the end.

Already fixed.

>
>       As of this writing, RS-232 is still strongly recommended as it
>       provides the following benfits:
>
> ==> s/benfits/benefits/

Fixed.

> 2.3.3 'Console' requires minimal functionality of attached devices.
>
> ==> uppercase first chars in words

Fixed.

>
> 2.5.7 Support Counters For Packets Dropped
>
> ==> s/Packets Dropped/Dropped Packets/

Fixed.
>
>    Examples.
>
>       Examples of this might include filters that permit only SNMP and
>       SSH traffic from an authorized management segment directed to the
>       device itself, while dropping all other traffic addressed to the
>       device.
>
> ==> (this may be semi-editorial) -- maybe s/other/other such/ -- you make a
> leap of faith that SNMP/SSH is the only thing the device needs (which might
> be OK for an ethernet switch, maybe, but certainly not routers I
> think :-).

This is just an example...not intended to be exhaustive.
 s/SNMP and SSH/SNMP, SSH and other managment traffic/

>
>      The definition of "significant" is subjective.  At one end of the
>       spectrum it might mean "the application of filters may cause the
>       box to crash".  At the other and would be a throughput loss of
>
> ==> s/and/end/ (last one)

fixed.

>
>    and TCP. It SHOULD support filtering of of all other protocols
>
> ==> kill extra "of".

OK.  Time for another global ispell passs.

>
>      The device MUST provide a logging facility that is based on
>       protocols subject to open review Section 1.8. Custom or
>
> ==> s/review/review, see/

s/review/review. See /

>
> 2.12.12 Ability to Assign Privilege Levels to Users
>
>    Requirement.
>
>       The device MUST be able to assign a defined set of authorized
>       functions, or "privilege level," to each user once they have
>       authenticated themselves the device.  Privilege level determines
>       which functions a user is allowed to execute.   Also see See
>       Section 2.12.11.

Fixed.

>
> ==> s/the device/to the device/
> ==> s/See//

Fixed.

Thanks,
---George