Re: Categorisation of SFRs for the TOE and for the IT environment

["YOKOTA HIROFUMI" <yokota-hirofumi@jqa.jp>]

IMHO, how about to specify SFRs for both the TOE and the IT environment?

Additionaly, you could put Application notes in the appropriate sections of
Security objectives, TOE security functional requirements and Security
requirements for the IT environment.

In the Application notes, you could state the acceptance of combinational
implementation.
Does this deviate CC concept ?

"Application notes" are defined as:

CC Part1 B.2.7 Application notes ( PP )
This optional section may contain additional supporting information that is
considered relevant or useful for the construction, evaluation, or use of
the TOE.

CC Part1 C.2.8 Application notes ( ST )
This optional part of an ST may contain additional information considered
relevant or useful for the understanding of the ST. Note that if the ST
claims compliance with the requirements of a PP, it may be appropriate that
certain informaiton contained in a potential application notes section of
the PP is incorporated into other sections of the ST. For example,
information concerning the construction of the TOE is probably more
appropriately preserved in the TOE summary specification or the ST rationale
than in a separate application notes section. To ease evaluation of the ST,
and given that the structure for the presentation of an ST outlined in this
annex is not normative, an application note containing evaluation relevant
material should be a part of the section of the ST that provides the
evidence for that evaluation aspect.

----- Original Message ----- 
From: "Agievich Sergei V." <agievich@bsu.by>
To: "Multiple recipients of list" <cc-cmt@nist.gov>
Sent: Thursday, April 01, 2004 7:17 PM
Subject: Categorisation of SFRs for the TOE and for the IT environment


>
> We plan to develop a PP for software cryptographic modules that run under
> a general-purpose operational system. During the preliminary analysis,
> we encounter a problem with categorisation of SFRs for the TOE (software
> module)
> and for the IT environment (operational system, OS).
> Let us illustrate this problem with an example.
>
> Let the τοε implement role-based access control policy.
> Before using the TOE functionality, an end-user must be identified and
> authenticated.
> The following implementations of I &A are possible:
>
> a) the OS identifies and authenticates end-users, and maps their identity
> to an OS role. The TOE roles are equivalent to the OS ones;
>
> b) the OS identifies and authenticates end-users, and maps their identity
> to the OS role "TOE User". Members of this role have access to the TOE
> authentication service. The TOE identifies and authenticates members
> of the role "TOE User", and maps their identity to a TOE role;
>
> c) the TOE identifies and authenticates all users of the OS, and maps
their
> identity
> to a TOE role.
>
> We suppose that any of the scenarios above can be implemented.
> Developers can choose a target scenario during the ST creation and their
> choice
> yields some combination of SFRs for the TOE and SFRs for the IT
environment.
> Now, how to declare all such combinations in the PP?
>
> In our opinion, the most flexible solution consists in the series of
> refinements
>
> "The TSF shall..." --> "The [selection: TSF, IT environment, TSF and IT
> environment] shall..."
>
> Does this solution meet the concept of the CC?
>
> P.S. We have been embarrassed by the following paragraph
> (CC, part 1, section 4.3.2):
> The intent of determining security objectives is to address all of the
> security concerns
> and to declare which security aspects are either addressed directly by the
> TOE or by
> its environment. This categorisation is based on a process incorporating
> engineering
> judgement, security policy, economic factors and risk acceptance
decisions.
>
>
> Sergey Agievich
> National Research Center for Applied Problems of Mathematics and
Informatics
> Belarusian State University
> Fr. Skorina av. 4, Minsk 220050, Belarus
>
>
>
>