RE: Question on security document

[Charles Monia <cmonia@NishanSystems.com>]

Hi:

I had assumed that one goal of the document was to set forth the language
necessary for each spec to pass muster with the IESG in the realm of
security.  If that's correct, I'm concerned that the suggested change may
compromise that intent.

Charles
> -----Original Message-----
> From: Robert Snively [mailto:rsnively@Brocade.COM]
> Sent: Wednesday, October 17, 2001 4:31 PM
> To: 'ips@ece.cmu.edu'
> Subject: Question on security document
> 
> 
> I have a recommendation to the authors of the security 
> document:
> 
> 	draft-ietf-ips-security-03.txt
> 
> There are a number of places where sentences like:
> 
> 	"Conformant iSCSI, FCIP and iFCP security 
> 	implementations MUST support
> 	both IKE Main Mode and Aggressive Mode."
> 
> are used.  I propose that all those "MUSTs", "SHOULDs", and similar
> words in the security document be changed to lower case as
> explained below.
> 
> According to the security document, it is informational, and never
> aspires to be more than an informational RFC.  If I
> understand RFC 2026 properly, Section 4.2.2 (attached below
> for reference) strongly implies that these documents cannot
> be used for verifying compliance.  However, RFC 2119 has
> a somewhat conflicted definition of how words like "MUST" 
> should be interpreted.  It says that they are rare
> and precious words that prevent very bad things from happening.
> It is implied that non-interoperability is one of those things and
> security failure is another.  It also implies that they rise
> no higher in requirement than the document itself.
> 
> I had expected that the iSCSI, FCIP, and iFCP documents
> were required to define their security compliance requirements.
> However, here we have an informational draft taking over that
> same job and using language that implies a compliance failure
> if the "MUSTs" are ignored.  It is not at all clear what would
> happen if one of the primary documents accidentally or purposely
> conflicted with the "MUSTs" of the security document.
> 
> I believe the best solution for this is to change all words
> in the security document with possible keyword meaning 
> to lower case, using the
> corresponding wording in each of the primary documents to 
> to uniquely specify by capitalization the truly important
> special keywords that will actually be used for conformance
> verification.  That keeps the informational document
> informational, prevents irresolvable keyword conflicts between
> the informational document and the primary documents, and allows
> the primary documents to do their compliance specification 
> without any danger of misinterpretation.
> By changing all words in the informational document to lower
> case, it will be very clear that the details contained in the
> primary documents supercede the text of the informational document.
> 
> ----------  Reference text from RFC 2026  -------------------------
> 
> 4.2.2  Informational
> 
>    An "Informational" specification is published for the general
>    information of the Internet community, and does not represent an
>    Internet community consensus or recommendation.  The Informational
>    designation is intended to provide for the timely publication of a
>    very broad range of responsible informational documents from many
>    sources, subject only to editorial considerations and to 
> verification
>    that there has been adequate coordination with the 
> standards process
>    (see section 4.2.3).
> 
>    Specifications that have been prepared outside of the Internet
>    community and are not incorporated into the Internet Standards
>    Process by any of the provisions of section 10 may be published as
>    Informational RFCs, with the permission of the owner and the
>    concurrence of the RFC Editor.
> 
> 
> --------------  Reference text from RFC 2119  -------------------
> 
> 
>    In many standards track documents several words are used to signify
>    the requirements in the specification.  These words are often
>    capitalized.  This document defines these words as they should be
>    interpreted in IETF documents.  Authors who follow these guidelines
>    should incorporate this phrase near the beginning of their 
> document:
> 
>       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
>       "OPTIONAL" in this document are to be interpreted as 
> described in
>       RFC 2119.
> 
>    Note that the force of these words is modified by the requirement
>    level of the document in which they are used.
> 
> 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>    definition is an absolute requirement of the specification.
> 
> ......
> 
> 6. Guidance in the use of these Imperatives
> 
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.
> 
> 7. Security Considerations
> 
>    These terms are frequently used to specify behavior with security
>    implications.  The effects on security of not implementing 
> a MUST or
>    SHOULD, or doing something the specification says MUST NOT 
> or SHOULD
>    NOT be done may be very subtle. Document authors should 
> take the time
>    to elaborate the security implications of not following
>    recommendations or requirements as most implementors will not have
>    had the benefit of the experience and discussion that produced the
>    specification.
> 
> 
> Bob Snively                        e-mail:    rsnively@brocade.com
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
>