Re: [xacml] request's attribute assertion lifetime?

[Polar Humenn <polar@syr.edu>]

On Thu, 4 Mar 2004, Frank Siebenlist wrote:

> I understand all the arguments, except that if you want to run scenarios where
> you want to test the access control decision in some point in the future by
> playing with the environment's notion of time, you're unable to note the
> possible expiration of the attribute assertions...

Either the attribute is there because it is "perceived" to be valid at
time T, or it is not present. Say I want to test an access decision for
some time T in a year from now.  If you have "attribute" certificates that
expire at time T-1, you shouldn't put those attributes in the request, as
they are not valid at time T.

> Furthermore, if we move to a model where we will accept individual authorization
> assertions as policy statements, and with these assertion is a validity interval
> associated, then we won't be able to store them in the database ...

Why not? I can store them in a database with as much meta data as I please
governing their validity. We do this with policies right now. There is no
argument at the PDP of whether a policy is valid or not. That is
determined by a higher authority.

> but will be forced to revalidate them before we feed them to the PDP/PAP
> every single time we use them.

If you base your storage model that way, then you are completely correct.
Furthermore, there is a lot more to validation than just time. You may
have to check the cryptographic signatures, the CRLs, various trust
arguments, etc, all which should be kept out of the access decision.

> It will also allow you to associate a upper-bound to the validity time interval
> of a decision.

I don't agree that this is a needed capability. Either access is granted
at time T based on valid information for time T, or it isn't.  Validity of
policy or policy elements is decided elsewhere.

> Maybe we should make the checking of time validity a mandatory thing in the
> xacml engine, meaning that we optionally associate validity intervals with
> attribute and policy statements, and if they are present,

I disagree.

> they will always be checked with the evaluation time.

There is no concept of "evaluation time".  Time is merely an environmental
attribute.  Hmmmm, what validity period does the time attribute have?

> So, no need to write any policy rule tests for time validity as it will
> be done for you automatically and always.

Time validity for a policy is governed by meta data about the policy, as
there are many different ways to accoplish this, it is nothing we should
standardize in XACML.

We might form another TC to adress the problem, but lets not start
throwing the worms in with the fish.

Cheers,
-Polar

> -Frank.
>
>
> Polar Humenn wrote:
>
> > On Thu, 4 Mar 2004, Frank Siebenlist wrote:
> >
> >
> >>I just came accross the fact that the request's attribute element has an
> >>optional InstantIssue element to indicate the date and time at which the
> >>attribute was issued, but you can't seem to specify a duration validity interval.
> >>
> >>Any reason for that?
> >
> >
> > All values attributed to resources, subjects, and actions pertinent to
> > the Access Decision Request should be validated for the request. (Another
> > reason why the PDP shouldn't supply the "current-time", a serious fault,
> > IMHO). The XACML Policy does not do validation. The PDP performs access
> > decisions based on valid information.
> >
> > The reason for this approach, is that we did not want XACML to become a
> > validation engine.  The business of checking signatures, validity times,
> > handling cryptographic computational complexity, is all out of scope, and
> > that is easily divided and pawned off on some other entity, so XACML will
> > have to complicate is job with those matters.
> >
> > As far as Time goes, I never liked IssueInstant being in the
> > ReqeustContext. Furthermore, you can't search on it using a
> > AttributeDesignator, so it's existence is really moot, except, I guess,
> > for the XPath folks.
> >
> > Cheers,
> > -Polar
> >
> >
> >
> >>Regards, Frank.
> >>
> >>--
> >>Frank Siebenlist               franks@mcs.anl.gov
> >>The Globus Alliance - Argonne National Laboratory
> >>
> >>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.
> >>
> >
> >
>
> --
> Frank Siebenlist               franks@mcs.anl.gov
> The Globus Alliance - Argonne National Laboratory
>