Heads Up: Security Requirements for Working Groups

["R.E. (Robert) Moore (254-4436)" <[e-mail]>]

Since Randy is requesting nontrivial Security Considerations
for the DLUR and HPR MIBs, I thought I'd forward this along to the
SIG / WG.  It sounds like what we need is a little boilerplate about
SNMP security in general, and then a discussion of the exposures
created by the specific contents of the two MIBs.

If anybody wants to take a shot at a Security Considerations section
for one of these MIBs prior to the AIW, it might expedite our
discussions.

Bob
----------------------------- Referenced Note ---------------------------
Date: Tue, 4 Mar 1997 17:31:20 -0500
To: [e-mail], [e-mail]
Sender:[e-mail]
From: Fred Baker <[e-mail]>
Subject: Heads Up: Security Requirements for Working Groups
Cc: [e-mail]

For your comment...

Some IAB, IESG, and Security folks have been meeting this week to discuss
the improvement of security analysis in Internet protocols. Over the past
few years, CERT Advisories and the media have made it brutally clear that
many protocols and many implementations are subject to various threats, and
writing a protocol or implementing a procedure that is naive in this regard
is at best silly and at worst a culpable disservice. Section 2.2 of RFC
1603, which indicates that the charter of a working group, and therefore
its documents, should address security among other things. We feel that
part of this is requirements of working groups in their charter and in
their resulting documents. I'd like to run some of the preliminary
recommendations by you for your comment.


Guidelines on writing Security Considerations in an RFC

A "threat" is, by definition, a vulnerability available to a motivated and
capable adversary. CERT advisories are quite predictable given a knowledge
of the target of the threat; they therefore represent an existence proof,
not a threat analysis. The point is to determine what attacks are possible
("capabilities" of a potential attacker) and formulate a defense against
the attacks, or convincingly argue that the attack is not realistic in some
environment and restrict use of the protocol to that environment.

Recommended guidelines:

  - All RFCs must meaningfully address security in the protocol or procedure
    it specifies. It must consider that it is giving its data to "the enemy"
    and asking it to be delivered to its friends and used in the manner it
    intended. Consideration must be given to the ramifications of the
    inherent danger of the situation.
  - Must do "due diligence" to list the threats to which the protocol is
    vulnerable. Use of legal term does not imply legal liability, but level
    of responsibility expected to be applied to the analysis. This discussion
    might occur throughout the document or in the Security Considerations
    section; if it occurs throughout, it should be summarized and referenced
    in the Security Considerations section.
  - Must discuss which of those threats are
        * Ameliorated by protocol mechanisms
          (example: SYN attack is ameliorated by clever code that drops
           sessions randomly when under SYN attack)
        * Ameliorated by reliance on external mechanisms
          (example: TCP data confidentiality provided by IPSEC ESP)
        * Irrelevant ("In most cases, MIBs are not themselves security
          risks; If SNMP Security is operating as intended, the use of a
          MIB to change the configuration of a system is a tool, not a
          threat. For a threat analysis of SNMP Security, see RFC ZZZZ.")
        * Not addressed by the protocol; results in applicability statement.
          ("This protocol should not be used in an environment subject to
            this attack")
  - Principle: new protocols and practices ought not worsen overall
    security of the Internet.
  - Principle: reuse an existing protocol or mechanism if possible...
  - When cryptographic algorithms are used, enable the substitution of
    other algorithms in the future
  - Should discuss implementation hints or guidelines
        * handle race conditions
        * handle buffer overflows/off-by-one issues
        * source code integrity
        * principle of least privilege
        * deal with untrustworthy data
        * deal with untrustworthy peer systems

Description of minimal Internet threat environment

Implied by the above is that the security folks need to provide an
Informational RFC that gives RFC authors a hand in doing the analysis. The
idea is not to impose a requirement - the requirement already exists, and
is handled today by back pressure during document last call and IESG review
- but to provide a tool that will help working groups and independent
submitters produce documents that do not result in that particular back
pressure. It lists classes of attacks and modes of analysis that the
security folks find useful. An initial goal is to post an internet draft in
April and deliver an initial RFC by August.

  - Classes of attacks in current CERT advisories are within the minimal
    threat environment
  - Other known classes of attacks may be as well
  - Should include a taxonomy/glossary of classes of attacks and terminology,
    with examples.
  - Republish periodically as IAB/IESG deem appropriate

Adding Security Requirements to WG Charters

  - Each WG is responsible for addressing security in its context
  - Each WG charter (including old ones, updated during 2Q97) contains at
    minimum the words "This working group acknowledges the importance of
    security in the overall internet architecture. Therefore, the protocols
    developed by this working group will be analyzed relative to RFCs XXXX
    and YYYY, to identify relevant security characteristics, dependencies on
    other security technology, and any residual vulnerabilities. This
    analysis will form the core of the Security Considerations section of
    the resulting RFC."
  - Each WG needs to work with "security volunteers" as it progresses
    its work.
  - No "Security will be added later"