RE: opsec and 2119 keywords

[George Jones <gmj@pobox.com>]

On Tue, 9 Mar 2004, Pekka Savola wrote:

> That is, we don't want to try to come to consensus
> what's the "blessed by the IETF"  security/operational minimal feature
> set.

I will let more IETFly minded people than I determine what "blessed by
the IETF means".   At the moment, we're looking at an INFO, not a
BCP or standards track doc with a possible follow-on working group
to do more official/BCPish things.

>  Even further than that, if the document says "SHOULD do Foo" --
> does the operator know whether the vendor does Foo or not -- it's not
> a strict requirement, and the vendor could be complying with the
> document, even though leaving out Foo?

SHOULD means SHOULD (at the moment, per 2119).

>  In that light, just saying "we
> implement [this document]" would not be sufficient for the operator to
> decide whether sufficient functionality has been implemented

No.  It's not.   The doc does not work a single-RFP-line-item
check-off.  It says "centralized authentication is important"
It does not say "thou shalt (?MUST?) implement [RADIUS|TACACS+|DIAMETER]".
It requires operators and vendors to *think* about what *types* of
features are required in order to plunk a box down in a large
network and operate it securely.   It is not intended as a
substitute for thought ("rfcXXXX compliant" ?, check).  It does
contain a reasonable collection  of thoughts on what the important
features are.  It has had relatively broad input.  It documents the
rational (see justification sections). It should help
both operators and vendors not to have to re-think at least these
issues, but it is not a substitute for thought.

[reordered quote]
> Then we leave it to the exercise of the operator/reader to decide
> which specific features they want.

This will always be the case.  Again, note the language that has been
added to the abstract (current working version):

04>   Operators and vendors should carefully consider the
04>   individual requirements listed here in the context of local policy,
04>   operational and security needs.  One size does not fit all.

> -- and
> the document would not fulfill its (current) role.
>
> Therefore it might be better to just describe features on their own,
> and use MUST/SHOULD/whatever keywords as appropriate to describe how
> the specific feature should/must be implemented _if_ it is
> implemented.

I noted during the BoF that a similar idea was out there previously.
The objection was that it would lead to "cherry picking".

I think this is an approach that should be explored further if a
working group gets going: Framework->Generic Requirement per device type(a la current
draft)->BCP implementation using current technology.

Thanks,
George M. Jones    |  Dilbert: "In the future, there will only be two kinds of
                   |  jobs. Technology jobs and lying to the public."