> I agree with Jim's opinion that FIA_SOS implies that the TOE does
> authentication.
> So, it would not be necessary to have a new component for the "strength of
> authentication".
>
> Similarly, though I do not know any particular mechanism for the stength of
> identification, FIA_USB looks performing the user identification.
>
> FIA_USB.1 User-subject binding
> FIA_USB.1.1 The TSF shall associate the appropriate user security
> attributes with subjects acting on behalf of that user.
>
> Regards,
>
> Yokota
I believe that this is a major problem with the implementation of the CC.
It can be said for each of the FIA requirements (at a minimum) that this
requirement, or that, "looks" like it requires a certain activity. This is
the basis for my previous arguments about intent, and some not so subtle
references to previous documents (e.g., those used by the TCSEC, ITSEC, or
CTCSEC).
Let me quote from NCSC-TG-009: Venice Blue Book ->
"The TCB shall require users to identify themselves to it before beginning
to perform any other actions that the TCB is expected to mediate. Furthermore,
the - TCB shall use a protected mechanism (e.g., passwords) to authenticate
the user's identity. The TCB shall protect authentication data so that it
cannot be accessed by any unauthorized user."
The above should lead to some very interesting questions (in my opinion).
1) Were those who drafted, and approved the CC, so incompetent that they could
not copy the three sentences cited above? Does this incompetence require that
those overseeing the CC need to interpret what they meant? Or, did those authors
put down in plain English what it was they wished to convey?
2) How come none of the CC FIA requirements specify any words similar to the
second and ESPECIALLY the third sentence? There is no mention of the TOE using
protected mechanisms or protecting authentication data - There is not even on
FIA requirement that "looks" like it does any of these requirements. It was
suggested that the FPT class would take care of this - however, if my memory
is correct only FPT_ITT.x mentions data protection, but that is for internal
data transfer, not storage. Additionally, as I have pointed out before, there
is no dependency (probably because one does not exist).
From this thread and others, it is abundantly clear that the CC is not the security
document that "security experts" envisioned it was supposed to be. That is a shame,
but as a Standard, expected to be adhered to by vendors/developers, evaluators, and
customers, it should not be subject to terms like:
intent;
looks like it means/covers;
etc..
As a standard, the words should be left to stand on their own, and not subject
to any ad-hoc review, with possibly subsequent continuous change, sometimes
multiple times in one year by those seeking to advance their own agenda.
As a standard, it should be employed as an engineering document since it is
based on engineering precepts - if any of those responsible for pontificating,
or interpreting the CC had to build a TOE based on the current state of the CC,
with its numerous interpretations would soon find that they could never hit this
"moving target" because they were told "it looks like," or "that was not the
intent."
It is for these reasons, that evaluations falter, users of the CC become frustrated,
and, in my opinion, will eventually implode - maybe this might be the goal of some,
rather than orderly, methodical change. I had one vendor contact me and say that
in the real world, "standards such as Energy Star, FCC, do change but at an upfront
with plenty of notice." The question is why is the CC different? Why cannot there
be products evaluated against (this is only for examples sake) Version 2.1 of the
CC and those evaluated against Version 2.2 - much the same as for FIPS 140-1 and
FIPS 140-2?
I believe there is room for pontification, and interpretation. However, the results
of such deliberations should only be evident in the "next proposed DRAFT" of the
standard. As I espoused before, let those requirements stand that are clear concise
singularly testable statements. Add to the standard if there is lacking a requirement
that addresses a particular security concern/intent. Let the users of the standard
comment on the proposed changes. Require the DRAFTERs to provide rationalization
(more than "we said so") for the changes. I further believe that all currently
involved with the CC are looking to improve security. It is not something that has
to be taught to the minions in the pits doing the work, or brought down by edict.
Halvar Forsberg
Senior Evaluator
Common Criteria Testing Laboratory
132 National Business Parkway
Annapolis Junction, Maryland 20701
(240) 456-6228
hforsber@csc.com
----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
----------------------------------------------------------------------------------------
"YOKOTA HIROFUMI" <yokota-hirofumi
@jqa.jp> Sent by: cc-cmt
10/03/2004 10:57 PM
Please respond to cc-cmt
To: Multiple recipients of list <cc-cmt@nist.gov>
cc:
Subject: Re: I-0480: Components Written As Environmental Actions
I said on Thursday, September 30, 2004 3:48 PM that:
>
> I think, (the new) FIA_UAU.3 is not necessary, because FIA_UAU.1/2 is
simple
> and sufficient to know the behaviour of function.
> Similarly, (the new) FIA_UID.3 is not necessary.
>
> Rather, I'd like to propose to add a requirement of "strength of
> authentication", a new component.
> As for user identification, I don't see "strength of identification" is
> required.
>
I agree with Jim's opinion that FIA_SOS implies that the TOE does
authentication.
So, it would not be necessary to have a new component for the "strength of
authentication".
Similarly, though I do not know any particular mechanism for the stength of
identification, FIA_USB looks performing the user identification.
FIA_USB.1 User-subject binding
FIA_USB.1.1 The TSF shall associate the appropriate user security
attributes with subjects acting on behalf of that user.