I-0415: User Attributes To Be Bound Should Be Specified

["Interpretations Working Group" <iwg@gibraltar.ncsc.mil>]

  This transaction consists of a proposal for a National Interpretation of
  a Common Criteria document. It is being posted in accordance with the
  procedures of the IWG.

  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 IWG@gibraltar.ncsc.mil in a form
  suitable for posting.  All comments should be posted no later than
  Monday, April 9, 2001.


                 CCITSE/CEM  NIAP INTERPRETATION (PROPOSED)


     _________________________________________________________________

            I-0415: User Attributes To Be Bound Should Be Specified
     _________________________________________________________________

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

TITLE:                User Attributes To Be Bound Should Be Specified
WOULD SUPERSEDE:
     I-0351           User Attributes To Be Bound Should Be Specified

SOURCE REFERENCE:     CC v2.1 Part 2 Subclause 7.6 FIA_USB.1
                      CC v2.1 Part 2 Subclause G.6 FIA_USB.1
RELATED TO:
     I-0351           User Attributes To Be Bound Should Be Specified
     I-0416           Association Of Access Control Attributes With Subjects An
d Objects
     I-0417           Association Of Information Flow Attributes W/Subjects And
 Information

ISSUE:

   PP/ST authors should be encouraged to specify which user attributes
   are to be bound to subjects created on behalf of a user.

STATEMENT OF INTERPRETATION:

   The component FIA_USB.1 is modified to provide an explicit assignment
   of attributes.

SPECIFIC INTERPRETATION:

   To address this interpretation, the following changes are made to CC
   v2.1, Part 2:


     * FIA_USB.1 is relabeled as FIA_USB.1-NIAP-0415. Unless otherwise
       noted in these changes, all normative and informative material
       associated with FIA_USB.1 is incorporated unchanged into
       FIA_USB.1-NIAP-0415, and all references to FIA_USB.1 in the CC,
       CEM, or other Common Criteria documentation are changed to refer
       to FIA_USB.1-NIAP-0415.

     * The FIA_USB.1.1 element is replaced with FIA_USB.1.1-NIAP-0415 as
       follows (additions marked _thusly_; deletions marked _[DEL:_
       thusly _:DEL]_ ):

     FIA_USB.1.1_-NIAP-0415_: The TSF shall associate the _[DEL:_
     appropriate _:DEL]_ _following_ user security attributes with
     subjects acting on behalf of that user_: [assignment: list of user
     security attributes to be bound]_.

     * In subclause G.6, the following text is added after paragraph
       1006:

     Operations

     Assignment:
     In FIA_USB.1.1-NIAP-0415, the PP/ST author should specify those
     user attributes that are to be bound to subjects created to act on
     behalf of users. At the time a PP/ST is developed, the PP/ST author
     knows the significant attributes of the FSPs of the TOE, and which
     of those attributes are to be derived from user-based information.
     Thus, it is possible for the PP/ST author to specify which user
     attributes are to be bound to subjects created on the user's
     behalf.

PROJECTED IMPACT:

   Negligible impact anticipated.

SUPPORT:

   At the time a PP/ST is developed, the PP/ST author knows the
   significant attributes of the FSPs of the TOE, and which of those
   attributes are to be derived from user-based information. Thus, it is
   possible for the PP/ST author to specify which user attributes are to
   be bound to subjects created on the user's behalf.

   However, in CC v2.1, the words of the FIA_USB.1.1 element use the word
   "appropriate". In order to specify the specific attributes to be
   bound, the PP/ST author must refine the element, and the evaluator
   must determine if the specified attributes are indeed "appropriate";
   further, the evaluator must determine if there are appropriate
   attributes not included in the refined element. This creates a risk of
   inconsistent evaluator interpretation.

   The ideal approach is to replace the need for refinement with an
   explicit assignment. The assignment should be driven by the attributes
   that are needed to enforce the TSP. For example, an access control
   policy based on user identity would require the user identity
   information be bound to the subject.

   Note: This interpretation is superseding a previously-approved formal
   interpretation primarily to reflect modifications to the
   interpretation format. The intent of the interpretation has not been
   changed, although some specifics of the criteria changes or the
   support may have been clarified or corrected.

0415.pdf