RE: I-0463: Hardware Inclusion In A TOE With FPT_SEP

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

On Wed, 17 Jul 2002 09:09:20 -0700, "Arnold, James L. Jr."
<JAMES.L.ARNOLD.JR@saic.com> said: 

> Why do I feel we are just going in circles?


Shall we dance?

> I suggest that the Oracle DBMS PP indicates an alternate approach because
> the NIB is indicating (in I-0463) that if you claim FPT_SEP you will almost
> certainly have to include hardware in the TOE. The Oracle DBMS PP serves as
> an example where that is not the case.

> I can't find where I-0463 indicates that there are no assumptions or IT
> security requirements related to FPT_SEP. Rather, the proposed
> interpretation indicates that if FPT_SEP is a TOE requirement it is very
> likely that hardware must be in the TOE.

As I said, I think you have highlighted an area where I-0463 needs to be
clarified. This is why it was posted for comment, not finalized. This is why
there is public involvement in the process through forums such as this, so
that the opposing views can be aired, discussed, and changes incorporated,
where appropriate.

> Regardless, I am addressing a more general concept and not what the proposed
> interpretation guidance says.

Well, we're on a chain related to the proposed interpretation, so that's my
focus.

> I certainly agree that there are disconnects between Part 1 and Part 3, but
> in this case I don't necessarily see any conflict. However, you seem to be
> indicating that assumptions must be limited to non-IT topics. Since the
> topic of "connectivity" certainly seems to be IT related, I don't think I
> can agree.

Connectivity is IT related, but it is not under the control of the IT. Rather,
it is under the control of the people who connect up the systems. I read the
words "IT environment" as things that are actually implemented in IT (hardware
and software).

> Requirements are interpreted despite the absence of any formally documented
> interpretations. Obviously someone in the UK decided that the Oracle DBMS PP
> was acceptable. If the implications in that PP are acceptable to the NIB
> then I'd certainly recommend writing an "else" clause in the proposed
> interpretation so that people aren't misled. If the NIB disagrees, then I
> guess more products will be going to the UK.

As I've said, I haven't read the Oracle DBMS PP closely. However, now that
you've brought it to my attention, I'll certainly look at it closer. Remember,
I don't speak for the NIB, but this forum is brought to their attention, so
hopefully the Oracle DBMS PP will be looked at to see how the guidance can be
improved.

> I think I indicated earlier that the words "maintain" and "implement" do not
> necessarily mean the same thing. Similarly, "maintain" and "provide" do not
> necessarily mean the same thing.

However, can you point to any strict interpretation of those words in the CC?

> My claim is that if a TOE/TSF is designed
> to operate (with code, data, etc.) within the boundaries it is given (by its
> IT environment), then it can be considered to be "maintaining" that
> environment.

I think I would agree with that, but the key words are the boundaries it is
given. Far too many profiles fail to give any boundaries. 

> The FPT_SEP informative text seems fairly clear in demanding
> that the domain of the TSF be separated from the domain of the untrusted
> subjects. I agree that the TOE must perform some function to meet the
> requirement, such as instantiating untrusted subjects in domains outside
> that of the TSF, but I disagree that it cannot have any help from its IT
> environment (provided that that help is clearly documented as either
> assumptions or requirements on the IT environment).

I think I would agree with that, given the proviso in your parenthetical
statement.

> Apparently we can't get past this point and hence I enter the Oracle DBMS PP
> into evidence to support my side.

Funny, I read this as we are pretty much in agreement, when appropriate
provisos are given.

P.S.: You still haven't given an indication whether you are going to read the
ASE proposal and comment on it.

Daniel