Re: HRAC decision object locality constrained?

[John Sebes <ejs@tis.com>]

Konstantin ,

Thanks for your thoughtful response. I still think that we are in more
agreement than you might think, and I still want to hone in on the critical
point which I don't think we articulated yet. I'll go steps along with your
responses.

>no. The ADO will reject a particular access operation on a particular
resource.
>More than one access operation on more than one resource can be performed
>during single CORBA request.
I didn't know that there was a many-to-one relationship between individual
access decisions and individual object invocations. I stand corrected. But
nevertheless, whether the unit of access control decision is operation or
something else, the point here is that the ADO can reject or accept a
requested access for reasons that can include QoP considerations. That is
all I was really trying to establish.

>> The QoP *policy* is the set of rules about when you should
>> or should't honor a request based on the level of protection it is. 
>
>I did not find a definition of "QoP policy". The spec defines only QoP:
>"QOP: Quality of Protection. The type and strength of protection provided
by a
>message-protection service."
Quite right. QoP is one area where the CORBAsec spec isn't as concrete as
in other areas.

>I would define QoP policy as a set of rules how messages sent and received by
>an application should be protected. There is difference between what you
wrote
>and what I wrote. In your definition, the stress is on honoring or not a
>request. In mine, on how a request or reply should be protected.
Yes, but ... protection is a two-way street. The sender of the request can
control the level of protection on the request. If the level of protection
isn't sufficient to meet the request-receiver's QoP policy, then the
receiver can reject the request (or reject access to an individual resource
the access of which is part of a request).

>> This kind of policy is very different from the "what level of protection 
>> will I use here," it is more like "did the other party use the right
level of
>> protection for my needs?"
>
>Try to look at the use of QoP information as yet another factor in a decision
>of authorizing a client to access resource x by using operation y. In that
case
>it becomes less controversial.
That is exactly how I look at it. The question is whether this use of QoP
should be tightly bound to othe HRAC mechanisms or rather might be a
security feature that is needed by many applications which do not need
HRAC. My suspicion is that the latter is the case (partly b/c QoP inclusion
in the CORBAsec spec, partly b/c personal experience). And my
predisposition as security architect is to not specify as integrated two
things which can be implemented separately.

>If ADO and QPE [QoP Policy Enforcer] will apply the same set of rules and
use the same set of factors
>in order to make a decision with the only difference that QoP information
will
>be excluded in making decisions by ADO, then I do not see a point in creating
>yet another object with almost the same logic behind it and the the same
>semantics of its service -- check if access is allowed.

The reason to separate them is because they are separate and because
sometimes one is needful without the other. In classical security
architectures, there can be a whole set of distinct but complementary
access control mechanisms that operate on the same data (what is being
accessed, who is accessing it) but enforce different rules. Access is
granted only if each distinct mechanism permits it. The
MAC/DAC/Integrity/DenialOfService distinction are examples of distinct
mechanisms enforcing distinct policies on the same kinds of access
requests. I suggest that CORBAsec access control (a la required rights),
and QoP, and HRAC, are similarly separate, separable, orthogonal,
complementary security mechanisms and policies.

That's my view anyhow. I'd be interested in hearing views from folks that
participated in the definition of the CORBAsec spec, esp. those involved
with HRAC.

-- John

----------------
Broadcast message to hrac-rfp from John Sebes <ejs@tis.com>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.