RE: [xacml] Re: env attributes

[Mike Burati <mburati@bowstreet.com>]

Pardon the intrusion from a mere observer on the list (and I admit to only
having time to keep up with a small fraction of the traffic on the list and
an even smaller fraction of the actual spec updates), but I have some
comments inline below...  If I'm way off base due to being behind on
understanding XACML, then just ignore me and move on...

>>which means that policies writers will have to manually compensate for
>>time (and date) variations. assuming >that you have a PDP in the central
>>timezone and a PEP on either coast, this presents something of a
challenge.
>
> Sure. There is no free lunch - if you want a "live" clock ticking
somewhere,
> you got to be careful (and may want to use GMT time or something...)

Whether or not you have a PDP in a different timezone than PEP, you have to
deal with dateTime values that may differ in Timezone (consider the scenario
where a multinational or even just US-wide enterprise has policy
admins/writers in multiple timezones even if they centralize their PDP in
their IT headquarter's TZ and keep PEPs local to the systems they're
protecting...).  So, you likely already have to deal with
converting/normalizing to a single timezone (eg, GMT) to do comparisons,
even for a PDP/PEP within a single timezone, no?

>as to auditing, if all PDP transactions are timestamped by the PDP as part
>of the logging process i don't see this an an impediment to centralized
>audits. any event can be mapped back to the point of request at the time
>of audit--a safer model in my mind.

I agree - audit records created by a PDP should be timestamped using the
PDP's clock, likewise for any audit records the PEP creates - use its clock.

> I agree that it does open the can of worms - but occasionally you need'em
to
> go fishing..
>
> I would also agree to not include "live" clock anywhere at all.  It can be
> done in an implementation if needed..

Which is a good reason to allow, but not require use of the timestamps,
right? (other than for audit logs where I presume it would be required
anyway).

Speaking of a can of worms - for those who want to make ultimate use of
timestamps in their authorization decisions:  One option "if" the decision
is made to stick with the PDP's clock for comparing against a policy
timestamp, would be to allow use of a Kerberos-like PEP to PDP
time-synchronization check where the PEP specifies that the PDP should
evaluate the policy IFF the PDP's current-time is within a given
(configurable) window of the PEP-current-time (normalized to GMT) included
in the context (pardon the terminology - as I said, I'm a bit behind the
curve on this one).  Sure, it leads to lots of runtime errors if you don't
synchronize your clocks (as I've seen lots of with Kerberos and DCE in the
past even in small enterprises), but it does give you the "option" of having
both the PEP's clock and PDP's clock contribute to the evaluation for those
that can't agree which is the correct choice.

..Mike