RE: Application TOE SFRs

["Daniel P. Faigin" <faigin@aero.org>]

I was rereading the interchange between Hal and me, as well as Jim's latest
postings, as part of capturing this for the NIB agenda (and yes, every posting
in this chain has been captured for the NIB to review at its next meeting;
this post will be Comment #26 in the chain). I noticed some stuff I missed
that I'd like to clarify:

Hal wrote:
> A good example are the FIA_UAU.1 and FIA_UID.1 requirements - I know there
> have been interps, but they serve to prove my point.

> FIA_UID.1 states: The TSF shall allow [assignment: list of TSF mediated
> actions] on behalf of the user to be performed before the user is
> authenticated.

> The English of the above statement is clear and concise. Nowhere in this
> requirement is the phrase "by the TOE/TSF/whatever" present. However,
> through the "intent" mechanism  words are added to the  requirement. This is
> how the engineering concept is "torn asunder." IF the  requirement does not
> specify the "intent of the author" the requirement should be removed from
> the CC,  or a new requirement that  captures "the intent" should be
> created. No, what is the Schemes answer -  provide PD-099, saying  that the
> English does not mean what the words say, they mean something  completely
> different, because the Scheme thinks they should. Then over 1/2 a year
> latter, an inter is  published that even changes that PD.

Before we look at this, let me note a number of constraints that CCEVS
operates under:

(1) We can't change or delete anything from the CC: That can only be done by
    the CCIMB, although we can make approved changes for US usage.

(2) Adding a new requirement means going through months of public review (the
    NI process), followed by having to have the CCIMB accept it, before it
    becomes official. Given the number of CCIMB meetings has been reduced and
    their priorities changed yet again, things progress even slower. Thus, any
    NI would be "optional" and likely ignored, making it a poor route to go.

Now, let's look at the element in question, which is actually FIA_UAU.1.1 (as it
refers to authentication). This can be considered to be an amgiguous element,
for (as note) it clearly indicates what the TSF must allow to happen before
authentication occurs, it doesn't indicate who does that authentication.

FIA_UAU.1.2 is potentially similarly ambiguous, stating that the TSF shall
require users to be authenticated (but not explicitly that the TSF must
perform the authentication). However, FIA_UAU.1.2 does use the phrase "before
allowing any other TSF-mediated actions...". So what does the "other" refer
to? It could be the authentication, or it could be the list in the assignment
in FIA_UAU.1.1. Again, an ambiguity. Boy, the writer of this component wasn't
very precise, and all of those folks that reviewed this didn't catch this.

Let's see if we can find any other clues. We know, from para. 268, that the
family defines the types of user authentication mechanisms supported by the
TSF. This doesn't say "provided", and it is unclear the distinction between
"supported by" vs "provided by". The annex similarly doesn't provide any
clarification.

So, what do we do when the question arises: Does this element require that
authentication be performed by the TSF? Jim is arguing (and I think Hal is
arguing) for the lenient position: it can be provided by an external
entity. CCEVS was arguing for the more stringent position, it must be provided
by the TOE itself.

Here's how I see the basis of the CCEVS decision. In the multiple
authentication case, FIA_UAU.5 has an explicit requirement that the TSF
provides a set of mechanisms. Yet there is no parallel requirement for the TSF
providing a single mechanism. Why? If the authors were having the foresight to
have FIA_UAU.1 apply to externally provided mechanisms, wouldn't they have put
in an explicit requirement that the TSF provide the authentication for the
cases where it was internal to the TSF? But they didn't. This implies
they must have felt it was covered by some other case, most likely
FIA_UAU.1/.2. So they just wrote sloppy.

There is also the situation fact that when the CC typically talks about
something provided by an external entity, it does so explicitly, refering to
external IT. It doesn't do so here.

As a result, CCEVS issued a PD, which takes effect when issued (without having
to wait for an NI) to give an immediate answer for other
evaluations. Recognizing, however, that there was an ambiguity, an NI was
developed, which started down the cycle right after the last meeting.

Hopefully, this clarifies the reasoning, and shows that there is some basis
behind what is claimed to be arbitrary intent. You may not agree with this
basis, it may not have been captured well, but it was more than "Let's just do
it this way."

Hal also wrote:
> May I make a suggestion - there are really two options that would satisfy
> this issue. 

> 1)    If the SFR is so poorly worded as to invite "confusion" without the
>       addition of other words - strike it from the standard. 

> 2)    If the SFR is worded in correct English, and is a single testable
>       statement, but does not meet some criteria for intent - leave the SFR
>       alone and  create another that meets the conditions for a requirement
>       statement and also  conveys the "intent." 

I've noted above why this can't be done. CCEVS doesn't have the authority to
"strike" something from the standard. It could only do that when it owned the
standard. It can issue a clarification to be used until the owning body
corrects the standard. It can create a new requirement, but this takes time
and must be officially accepted by the owner.

Lastly, Hal noted:
> Just an aside, I find that the rationalization by the validator and Scheme
> regarding this issue, made vague references to the intent of TCSEC, CTCSEC,
> and  ITSEC. However, I find it strangely curious that if the intent of the
> I&A requirements  harken back to those "standards" there has been no
> published activity by any Scheme to  address the issue of the
> storage/handling of the identification and/or  authentication data used by
> the I&A mechanism. One would think that if the intent of the  authors of the
> documents were to follow previous security standards, this issue would  seem
> to be rather important and the "intent" should be actively codified! 

Ah, but the issue of "storage/handling of the identification and/or
authentication data used by the I&A mechanism" is addressed. Such data falls
in the category of TSF data, and there are requirements to protect TSF
data. Originally (I forget if it was pre-v1.0 or in v1.0), there were separate
data protection requirements in each of the families. At some point, the
committee working on the CC felt that the document was getting too big, and
combined all of these into a management of TSF data. I think it was in the
move from 1.0 to 2.0, but perhaps Jim, Ron Bottomly, or Mario Tinto remember
better.

Jim wrote:

> While I certainly agree that the scheme has justified many position based on
> intent, they have now started to base decisions based on the potential that
> a consumer might be confused in some manner. We apparently are to assume
> that consumers don't know anything about the CC and that they will read only
> some selected parts of an ST, for example, and hence those parts need to
> better represent the whole.

Well, I can't speak to all who support the scheme, but in what I do, I know
the end consumers. Not only does my employer support CCEVS, but we also
support the DoD in acquisition. In the folks I deal with, they have little
knowledge of the CC, and if we're lucky, only skim parts of the ST. So, yes,
we do need to think about the end consumers: the people having to read the STs
and the reports produced in order to make buying decisions. 

We often forget that focus. We think about how to make it easier for the lab,
for the scheme. That's not why we're here. We're here to support the
customers: be the DoD (as in my case) or other customers. 

Labs also have to please their sponsors: the last thing a sponsor wants is an
unhappy purchaser of the product, who misunderstood the security provided by
the product. This turns them off from future purposes. Thus, I would believe
it is in the lab's interest to ensure the product is described clearly and
accurately.

Let's keep our focus on serving the customer: the end purchaser of these
systems who will be placing trust in these systems to protect their data from
some threat. Depending on who the customer is, our lives may depend on it.

This is why I detest the fighting over the criteria lawyering so much. If an
ST or PP author feels there may be an ambiguity in a requirement: clarify it
so it is clear. Don't always place the burden on someone else, and hope you
can fly under the RADAR. Make it clear and unambiguous. It serves you. It
serves the customer.

> I tend to think that too much effort is being applied to nail down the
> precise meaning of each and every requirement. I tend to believe that
> requirements should really only be understood or specified at a fairly
> general, abstract level and it is up to the TSS clarify the answer more
> precisely. I also tend to think that implementations should not be dictated.

But if one doesn't understand the meaning of a requirement, how can one make a
statement that it is satisfied? One shouldn't have to go to further
explanation to do so. I'm not saying that the requirements should dictate the
implementation. Rather, they should be clear, unambiguous, and testable. Is
that too much to ask? 

>> Finally, you brought up the issue of money. Well it is not the way to run
>> an entity that is both an international and national standard by saying -
>> we cannot "do it" correctly because of money, but we will throw something
>> out, right or wrong, but we will do our best, given the funds we have.
 
> I have to admit I was surprised this was brought up. The Scheme should be
> prioritizing its resources efforts as best it can, it should elicit help
> from the community where it can, and the rest of the government should help
> if it truly supports the program.

I brought the issue simply to point out that, although many problems could be
fixed in an environment of infinite money and infinite resources, we don't
have that. Thus, we must understand that as a result, there will be some
compromises made in the process.

Daniel