|
Thanks Gary,
I would say the guidance I-0451 clarifies
the use of IFF/IFC and ACF/ACC sufficiently,
Yet, here are one additional
question and two minor suggestions.
1. typographical consistency
AFF/AFC --(correct to)--> ACF/ACC ( at the
title, at the STATEMENT )
ACC/ACF --(correct to)--> ACF/ACC ( at the
ISSUE )
2. The ISSUE
states:
In particular, for an environment where there
is an externally defined policy and no attributes on objects, should IFF/IFC be
used?
Although the guidance clarifies the use of
IFF/IFC and ACF/ACC, I do not see the answer in the
guidance.
If 'yes', 'no' or 'depend
on' answers are put in the guidance regarding this question, this would
make readers easier to understand and prevent
confusion.
3. question
Let's see a typical information flow control
in a firewall as follows:
- The controls are based on a sensitivity
label on the information.
- Sunjects are not involved in the flow
control.
- (i.e., Subjects do not have
active roles in the flow control.).
In this flow control and based on the CC
paradigm, who does create information? Network hosts? or the
firewall(TOE)?
In the natural sense, information is created
in network hosts and passes through the firewall.
Then, how could we deal with FMT_MSA.3.2 that
addresses information creation as follows:
The TSF shall allow the [assignment: the
authorised identified roles] to specify alternative initial values to override
the default values when an object or information is created.
My understanding is that the firewall(TOE)
does not create information in this flow control, so FMT_MSA.3.2 is vacuously
satisfied and omitted.
Is this understanding
correct?
Yokota
----- Original Message -----
Sent: Friday, October 31, 2003
11:47 PM
Subject: Re: I-0451: When To Use
IFF/IFC ( What is fundamental characteristic of information)
The phrase "fundamental characteristic of the
information" is used in the context of security attributes. Message
length is not usually a security consideration, yet might be. For
example, if security policy prohibits email messages longer than a specified
amount (perhaps to prevent sending files via email), then flow control
components would be appropriate for that situation.
Existence and
correctness of a hash value could also be part of an information flow control
policy and hence appropriate for IFF/IFC. The relation to UIT might be
that UIT results in mechanisms to attach integrity checks to messages being
transmitted as part of the transmission process. An information flow
control mechanism would more likely be one that looks for messages coming for
transmission to see that a valid hash or checksum has been generated as part
of the message creation process. If the goal is transmission integrity,
then UIT is the more obvious choice. If the goal is to ensure that
messages to a certain transmission pipe have certain controls built into the
message, then IFF/IFC could be the better choice. I do not claim that
this is a useful distinction, but it might
be.
Cheers,
Gary
At 10:08 PM 10/30/2003, YOKOTA HIROFUMI
wrote:
Overall, I agree with Nir and
read the guidance such that it allows for
IFF/IFC to be used for
applications such as firewalls, routers, etc.
However, as Michelle
says, this might be depending of my background and
interpretaion.
It
is hard to read some nuances if there are in the proposal, for those
who
are
not involved in discussions at the days of
TCSEC.
Putting aside the nuances, I have another
question.
What is the meaning (or definition) of "fundamental
characteristic of the
information"?
1. Is a message length that is
written on a part of information field a
fundamental characteristic of
the information?
=> I think so. The length value stays on the
information and and is
definitely associated to the
information.
2. Is a message length that is not written on the
information field a
fundamental characteristic of the
information?
=> I think so. The length valuse is definitely associated
to the
information even if it is not written on some part of the field of
the
information.
In a similar way:
3. Is a hash value that
is written on a part of the information field a
fundamental
characteristic of the information?
=> I think so. The hash value stays
on the information and is
definitely associated to the
information.
Then, finally:
4. Is "valid or invalid" values
that is resulted in a caluculation by a
particular algorithm in the TOE,
based on the hash value and the
information, a fundamental characteristic
of the information?
=> I am puzzled.
***********
The
reason why I raised this question is because that some evaluated
STs
demonstrate the valid/invalid values as information security
attributes, and
the rules based on the attributes controls deny/permit
information flows by
using IFC/IFF.
Is this an appropriate use of
IFC/IFF?
Could "valid/invalid" values resulted from the hash values
and the
information
in the TOE using some algorithm be an information
security attribute?
If "yes", I would say, this is an great
idea!
For many months, I was pondering about how to craft IFC/IFF
that is required
as a dependency for FDP_UIT (Data exchange
integrity).
I was given many suggestions about this, but my worry didn't
terminate.
If valid/invalid values resulted in the TOE is used as
information security
attributes and this is an appropriate use in
IFC/IFF, I would say this could
be
a final answer for my worry about
crafting IFC/IFF that is required as an
dependency
for
FDP_UIT.
However, I have some doubts on this as follows.
1) It
looks that IFC/IFF depends on FDP_UIT, rather than that FDP_UIT
depends
on
IFC/IFF.
2) Once 'valid/invalid' status was generated by TSF in
the TOE, is it
truely necessary for the TSF further support the
information flow control
based on
the status? What is the threat to
counter? I think such chained inclusion of
components would make the ST
further complex unnecessary.
3) Please note that TSF generate
valid/invalid status for FDP_DAU (Data
authentication) and FDP_SDI
(Stored data integrity), too.
However, those components, in the CC
specification, do not depend on
IFF/IFC. Yet, is it appropriate to
use IFF/IFC based on the rules of
'valid/invalid' status when some
subject in the TOE read those user data?
( Which, I think it is not
necessary.
)
Yokota
================================
Hirofumi
Yokota
Japn Quality Assurance Organization
E-mail
yokota-hirofumi@jqa.jp
**************************************************************************
*
Opinions expressed are not intended to reflect an official
position
**************************************************************************
*
Gary Stoneburner
* Computer Security Division, National Institute of
Standards & Technology
* 100 Bureau Drive, Stop 8930, Gaithersburg, MD
20899-8930
* Phone:
301-975-5394, FAX: 301-948-0279, Email: Stoneburner@nist.gov
* http://csrc.nist.gov/staff/stoneburner/gshome.html
**************************************************************************
|