I-0482: Properties Of Default Values For Attributes

["NIAP Interpretations Board" <faigin@aero.org>]

  The following is a proposal for formal CCEVS guidance related to the
  Common Criteria and ancillary documents. It is being posted in
  accordance with the procedures of the NIB.

  Comments on this proposal are welcomed and should be posted to this
  transaction chain.  If any party wishes to post a comment anonymously,
  the comment should be mailed to cc-cmt@nist.gov in a form suitable for
  posting.  All comments should be posted no later than Monday, January
  10, 2005.


                 CCITSE/CEM  NIAP INTERPRETATION (PROPOSED)

     _________________________________________________________________

              I-0482: Properties Of Default Values For Attributes
     _________________________________________________________________

TYPE:                 NIAP Interpretation
NUMBER:               I-0482
STATUS:               Ready for External Review

TITLE:                Properties Of Default Values For Attributes
COMMENTS DUE BY:      Monday, January 10, 2005 to cc-cmt@nist.gov

SOURCE REFERENCE:     CC v2.1 Part 2 Subclause 8.2 FMT_MSA.3
                      CC v2.1 Part 2 Subclause H.2 FMT_MSA.3
RELATED TO:
     I-0442           Restrictive Is Not Fully Defined Without Specification Of
 Attributes

ISSUE:

   What exactly are "restrictive" and "permissive" default values,
   offered as selections in FMT_MSA.3.1?

   It seems that these terms are ambiguous. Permissive could mean to
   allow all possible accesses or information flows or alternately to
   allow only some of the possible accesses or information flows.
   Similarly, restrictive could mean to deny all possible accesses or
   information flows or to deny only some of the possible accesses or
   information flows.

   Part 2 doesn't seem to offer any insight into precisely what these
   selection options are supposed to indicate. Barring any guidance, it
   seems one could assume that the specific nature of restrictive and/or
   permissive could vary from TOE to TOE, much like it is left up to an
   ST author to define what "reliability" means in relation to FPT_STM.1.

STATEMENT

   The PP/ST author shouldn't be bound by nebulous terms such as
   "permissive" or "restrictive". The characteristics used to govern
   default values should be able to be unambiguously specified by the
   PP/ST author.

RECOMMENDED CRITERIA CHANGES

   The following changes are CC V2.1 Part 2 Subclause 8.2 FMT_MSA.3, as
   modified by I-0442:

     FMT_MSA.3.1. The TSF shall enforce the [assignment: access control
     SFP, information flow control SFP] to provide _[DEL:_ [selection:
     restrictive, permissive, [assignment: other property]] _:DEL]_
     default values for the following security attributes that are used
     to enforce the SFP: [assignment: list of security attributes in the
     scope of the identified SFP to which the _[DEL:_ restrictive,
     permissive, other _:DEL]_ default value property should apply].

     _FMT_MSA.3.2. The TSF shall ensure that the default values for the
     attributes satisfy the following rules: [assignment: for each
     attribute, an unambiguous specification of default value property
     rules for that attribute]._

     FMT_MSA.3._[DEL:_ 2 _:DEL]_ _3_. _For each of the following
     attributes, the_ _[DEL:_ The _:DEL]_ TSF shall allow _[DEL:_ the
     [assignment: the authorised identified roles] to specify _:DEL]_
     alternative initial values _to be specified by the indicated roles_
     to override the default values for these attributes when an object
     or information is created_[DEL:_ . _:DEL]_ _: [assignment: table of
     attributes and the authorised identified roles permitted to
     override the default values for those attributes]_

   The following is added to CC V2.1 Part 2 Subclause H.2, under
   Assignment:

     In FMT_MSA.3.2, the PP/ST author should describe, for each
     attribute covered by this component, the desired characteristics of
     the default values. For example, this might specify that these
     values give minimal access (restrictive) or provide maximal access
     (permissive). The rules can also be used to describe inheritance of
     attributes. In any case, the rules should use clearly defined
     terminology.

   The following is changed in CC V2.1 Part 2 Subclause H.2, under
   Assignment, paragraph 1033:

     In FMT_MSA.3._[DEL:_ 2 _:DEL]_ _3_, the PP/ST author should _[DEL:_
     specify _:DEL]_ _provide a table that specifies, for each attribute
     for which default override capabilities are desired,_ the roles
     that are allowed to modify the _default_ value of the security
     attributes. The possible roles are specified in FMT_SMR.1.

SUPPORT:

   It has been indicated that the intent of the CCIMB, in CC v3.0, is on
   the side of flexibility, i.e.,

     MSA.3.1 The TSF shall ensure that [assignment: security attribute]
     has a default value of [assignment: value] when the object, subject
     or information that it belongs to is created.

     MSA.3.2 The TSF shall allow [assignment: subject] to change this
     default value.

   However, this doesn't work well in the CC v2.1 paradigm where it needs
   to be tied to a policy to define the attributes. Further, it doesn't
   allow the PP/ST author to indicate the desired characteristics for the
   default, leaving it open for the ST author to select. Yet there are
   problems with retaining the stock cc v2.1 solution, which used
   ill-defined terms ("restrictive", "permissive"). The approach taken in
   this interpretation is the middle ground: allow the specification via
   assignment, yet still provide for default values.