[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issues: policy vs. mechanism
I think your Requirements SHOULD describe requirements, not policies. I
think referring to requirements as policies is unnecessary obfuscation. I
recommend avoiding the use of the word policy, but if you do want to use
policy, then you should keep your terminology consistent with RFC 3198.
We have a requirement: vendor equipment must have the ability to support
confidentiality and integrity of login sessions.
We may have a second requirement: vendor equipment must implement the SSH
mechanism to support confidentiality and integrity of login sessions
(although I think this should be a recommendation, not a requirement, since
other mechanisms could be used to achieve the first requirement).
A business policy may define a plan or course of action: the SSH mechanism
must be enabled and used to achieve confidentiality and integrity. But it is
not an IETF requirement that confidentiality and integrity be enabled, or
that operators use SSH to achieve these. (Since this is a BCP that suggests
following a set of actions, maybe we should call these "recommendations to
re.quire.ment ( P ) Pronunciation Key (r-kwrmnt)
Something that is required; a necessity.
Something obligatory; a prerequisite
pol.i.cy1 ( P ) Pronunciation Key (pl-s)
n. pl. pol.i.cies
A plan or course of action, as of a government, political party, or
business, intended to influence and determine decisions, actions, and other
matters: American foreign policy; the company's personnel policy.
A course of action, guiding principle, or procedure considered expedient,
prudent, or advantageous: Honesty is the best policy.
Prudence, shrewdness, or sagacity in practical matters.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of George
Sent: Wednesday, July 07, 2004 9:32 AM
Subject: Issues: policy vs. mechanism
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
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
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.
00> Requirement (what)
00> The requirement describes a policy to be supported by the device.
00> For example, "The device MUST support secure channels that allow
00> in-band access to all management and configuration functions."
00> Requirements should not refer to specific technologies. It is
00> expected that requirements will change little over time.
00> Justification (why)
00> The justification tells why and in what context the requirement is
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> The justification is intended to give operators information needed
00> to determine the applicability of a requirement to their local
00> Examples (how)
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> 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> 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> Warnings (if applicable)
00> The warnings list operational concerns, deviation from standards,
00> caveats, etc.
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