Re: Reply to comments on opsec draft from Bert Wijnen/OPS directorate. Part 1.

[George Jones <gmj@pobox.com>]

...continued

bw> Date and Time: 2004-01-25, 18:13:52
bw> Version: 03
bw> Commented by: Wijnen, Bert
bw> State before Comment: 0
bw> State after Comment: 0
bw> Comment: ----------------
bw> comments from OPS Directorate
bw>
bw>
bw> Section 2.1.1
bw>
bw> I was expecting some specific guidance here.  For example, support for
bw> SNMPv3, SSH, etc. Instead, this section just talks about some ways
bw> that things *might* be secured.  Based on this section, I guess one
bw> could use SNMPv2 over TLS over TCP *or* SNMPv3 *or* SNMPv2 over IPsec
bw> to secure management traffic and be compliant. If the goal is to use a
bw> management station to securely manage devices, that level of guidance
bw> is not helpful.

What this is trying to say is that devices that use unencrypted
telnet, http and SNMPv1 for management fail the requirements.

Earlier (pre-IETF) versions said things like "use SSH", but I was
advised that such sepcific requirements would cause the doc to become
quickly dated and preclude advances (such as netconf) that met the
spirit of the requirement.

Following that advice, I've tried to make the *requirements* generic
principals that codify things that are done today (current practice)
and the examples section cite one or more
current-at-the-time-of-writing technologies that meet the requirement.

Different organizations at different times will have different
required implementations.

BCP seemed to be the closest fit for this doc in IETF space, but it
was not a perfect match.   This may be showing one of the mismatches.

Perhaps this makes it more of a "framework" document?

bw>
bw> Per-packet integrity protection doesn't guarantee that the log files
bw> won't get modified.

No, but it increases the work to do so.  One has to then modify the
data at the sending end, mess with the encrypted data in transit, or
modify it on the recieving end.

bw>
bw> "Protocols that use encryption"
bw>
bw> Is it being suggested that traffic should or must be encrypted?  That
bw> these protocols should or must be implemented? I'm not sure.
bw>
bw> Is it being suggested that transmission layer encryption (not even
bw> integrity protection) would address BGP-related security threats?
bw> Reference to some of the BGP security documents might be helpful.
bw>
bw> "Protocols that do not use encryption:" Is this an attempt to
bw> recommend that secure equivalents be used instead of insecure
bw> alternatives?  If so, then the text should say this and supply
bw> specific recommendations."
bw>
bw> Warnings. The use of encryption does not guarantee that the protocol
bw> is secure."
bw>
bw> OK.  So what is the recommendation?

See if this is clearer.

04> 2.1.1 Support Secure Channels For Management
04>
04>    Requirement. The device MUST provide mechanisms to ensure
04>      end-to-end integrity and confidentially for all network traffic and
04>      protocols used to support management functions.  This MUST include
04>      at least protocols used for configuration, monitoring,
04>      configuration backup and restore, logging, time synchronization,
04>      authentication, and routing.
04>
04>    Justification. Integrity protection is required to ensure that
04>       unauthorized users cannot manage the device or alter log data or
04>       the results of management commands.  Confidentiality is required
04>       so that unauthorized users cannot view sensitive information,
04>       such
04>       as keys, passwords, or the identity of users.
04>
04>    Examples.
04>
04>       See [RFC3631] for a current list of mechanisms that can be used
04>       to support secure management.
04>
04>       Later requirements discuss in-band management (Section 2.2) and
04>       out-of-band management (Section 2.3) as well trade-offs that
04>       must be weighed in considering which is appropriate to a given
04>       situation.
04>
04>    Warnings. None.

The requirement is support for security for all management operations.
The implementation will vary over time.  The IAB has very recently
come out with a very good review of current security mechanisms in
RFC3631, which is now cited.

An earlier draft of this document had a table here listing protocols
groupd by function (logging, monitoring, etc.) vs security requiremnts
(e.g. NTP may need authentication, but it does not need
confidientiality).  As the doc morphed into the current form, the
table went away becuause it be became clear that for some areas
important to secure operations, such as logging, there were no
fully standardized, widely deployed secure options (see the fine
work of Chris Lonvick and the syslog WG, also see SSH WG).  The
lack of standardization ment ?that they could not be cited in a BCP?.

By this logic, I wold have to drop several things entirely out of the
draft (and already have droped several into the info-00 draft), but
the ability to perform all managment fucntions securely, whether or
not there are fully standardized, widely deployed solutions is
important enough that it needs to be said.  I leave it up to those
more into IETF processes to advise me how to proceed on this one.

...continued again.

Thanks,
---George Jones