Issues: policy vs. mechanism

[George Jones <gmj@pobox.com>]

We need to have a discssion about policy vs. mechanism.

In the current framework document, a requirement is defined as
specifying a "policy".  See below.

The thinking behind this is that "security" is mostly about
implementing policies.  We use SSH because we have a (possibly
implied) policy that we want confidentiality and integrity of login
sessions.  We use AAA serers because we want to assure that only
authorized individuals can access devies for management.  The policy
is "supports integrity".  The mechanism (today) is "use SSH
(IPSec)..."

To that end, the format below proposes that "requrements" list
policy statements to be supported and that examples list ways
that the policies can be supported using curent technology and
standards.

Please look this over and see if you think this is right.
See if you think it fits with IETF usage.   Suggest changes
if need be.

Thanks,
--George

00>   Requirement (what)
00>
00>      The requirement describes a policy to be supported by the device.
00>
00>      For example, "The device MUST support secure channels that allow
00>      in-band access to all management and configuration functions."
00>
00>      Requirements should not refer to specific technologies. It is
00>      expected that requirements will change little over time.
00>
00>   Justification (why)
00>
00>      The justification tells why and in what context the requirement is
00>      important.
00>
00>      For example, "Secure channels are important because they insure
00>      confidentiality, and integrity.  This is important in contexts
00>      where management is performed in-band over networks with
00>      potentially hostile users."
00>
00>      The justification is intended to give operators information needed
00>      to determine the applicability of a requirement to their local
00>      environment.
00>
00>   Examples (how)
00>
00>      Examples are intended to give examples of technology and standards
00>      current at the time of writing that meet the requirement. Examples
00>      of configuration and usage may also be given.
00>
00>      For example, "SSH provides access to management and configuration
00>      functions via secure channels. One way to meet this requirement
00>      might be to enable SSH for in-band management and to disable all
00>      insecure in-band management mechanisms (e.g. telnet, SNMPv1,
00>      etc.)"
00>
00>      It is expected that the choice of implementations to meet the
00>      requirements will change over time. See [RFC3631] for a list of
00>      some current mechanisms.
00>
00>   Warnings (if applicable)
00>
00>      The warnings list operational concerns, deviation from standards,
00>      caveats, etc.
00>
00>      For example, "If SSH is chosen as the mechanism to provide secure
00>      channels for remote management and configuration, then there are a
00>      number of issues which must be considered including key
00>      distribution and known vulnerabilities in various protocol
00>      versions."