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

TYPE:                 NIAP Interpretation
NUMBER:               I-0351
STATUS:               Formally Superseded

TITLE:                User Attributes To Be Bound Should Be Specified
SUPERSEDED BY:        
     I-0415           User Attributes To Be Bound Should Be Specified

EFFECTIVE:            2000-03-27
SUPERSEDED:           2002-05-14

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-0353           Association Of Access Control Attributes With Subjects And Objects
     I-0354           Association Of Information Flow Attributes W/Subjects And Information
CCIMB ENTRY:          CCIMB-INTERP-0102

STATEMENT

The following interprets the FIA_USB.1 component:

PP or ST authors must be able to explicitly specify the user security attributes to be bound to subjects created on behalf of a user; refinement of the phrase "appropriate" is too vague.

RECOMMENDED CRITERIA CHANGES

In order to address this interpretation, the following changes should be made to FIA_USB.1.1: (additions marked thusly; deletions marked ~~thusly~~):

FIA_USB.1.1: The TSF shall associate the ~~appropriate~~ following user security attributes with subjects acting on behalf of that user: [assignment: list of user security attributes to be bound].

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.

This interpretation should be distinguished from I-0353/I-0354, which discuss the security attributes bound to subjects, for not all subject security attributes derive from user attributes.