OASIS eXtensible Access Control Markup Language (XACML) TC

Dear WG

I dont know if this issue has already been discussed before by the group 
(I suspect it might have), but we have the following problem.

The java interface to our PDP includes validity times for each subject 
attribute. This allows attribute assertions (SAML, X.509 etc) to be 
validated once in our  validation software (a time consuming process 
especially if they are signed) and then used many times for multiple 
decisions by the PDP.

We have added an XACML request context interface to our PDP, but now 
when the attributes are converted into XACML subject attributes, we lose 
the validity times that our validation software has extracted and placed 
alongside each attribute value.

We could produce a "hack" workaround by adding an addition validity time 
attribute to the set of subject attributes, but in the general case each 
subject attribute can have different validity times, especially when 
attribute assertions are obtained from multiple attribute authorities.

If the group has discussed this topic, what was your conclusion

regards

David

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

David,

XACML is currently based entirely on a model where only the current, 
valid attributes are presented to the PDP for each particular decision. 
It is assumed that the PEP/context handler has already validated the 
attributes.

If your policy requirement is that an attribute be valid, for instance, 
many countries require that a passport is valid for at least six months 
before they let you into the country, you can model this with a specific 
attribute, like a "passport validity end date" in this case.

Regards,
Erik

David Chadwick wrote:
> Dear WG
>
> I dont know if this issue has already been discussed before by the 
> group (I suspect it might have), but we have the following problem.
>
> The java interface to our PDP includes validity times for each subject 
> attribute. This allows attribute assertions (SAML, X.509 etc) to be 
> validated once in our  validation software (a time consuming process 
> especially if they are signed) and then used many times for multiple 
> decisions by the PDP.
>
> We have added an XACML request context interface to our PDP, but now 
> when the attributes are converted into XACML subject attributes, we 
> lose the validity times that our validation software has extracted and 
> placed alongside each attribute value.
>
> We could produce a "hack" workaround by adding an addition validity 
> time attribute to the set of subject attributes, but in the general 
> case each subject attribute can have different validity times, 
> especially when attribute assertions are obtained from multiple 
> attribute authorities.
>
> If the group has discussed this topic, what was your conclusion
>
> regards
>
> David
>

Hi Erik

the problem is when you have a chain of processing elements (PIPs, PDPs, 
context handlers, CVSs, PEPs etc as in Globus Toolkit) and you want to 
use the XACML request context as the standard carrier protocol between 
each of the elements. An element somewhere in this chain has to perform 
the attribute validity time testing. It does not have to be the PDP. But 
the XACML RC does not allow the validity times to be packaged with each 
attribute.

Yes, you can implement the hack you mention below, where you add a new 
validity time attribute for every RC subject attribute, but a better 
solution would to be to change the XML to allow optional validity times 
to accompany each attribute, with default values of start now and never 
end. This achieves backwards compatibility, but allows validity times to 
be incorporated naturally with attribute values.

What do you think?

regards

David


Erik Rissanen wrote:
> David,
> 
> XACML is currently based entirely on a model where only the current, 
> valid attributes are presented to the PDP for each particular decision. 
> It is assumed that the PEP/context handler has already validated the 
> attributes.
> 
> If your policy requirement is that an attribute be valid, for instance, 
> many countries require that a passport is valid for at least six months 
> before they let you into the country, you can model this with a specific 
> attribute, like a "passport validity end date" in this case.
> 
> Regards,
> Erik
> 
> David Chadwick wrote:
>> Dear WG
>>
>> I dont know if this issue has already been discussed before by the 
>> group (I suspect it might have), but we have the following problem.
>>
>> The java interface to our PDP includes validity times for each subject 
>> attribute. This allows attribute assertions (SAML, X.509 etc) to be 
>> validated once in our  validation software (a time consuming process 
>> especially if they are signed) and then used many times for multiple 
>> decisions by the PDP.
>>
>> We have added an XACML request context interface to our PDP, but now 
>> when the attributes are converted into XACML subject attributes, we 
>> lose the validity times that our validation software has extracted and 
>> placed alongside each attribute value.
>>
>> We could produce a "hack" workaround by adding an addition validity 
>> time attribute to the set of subject attributes, but in the general 
>> case each subject attribute can have different validity times, 
>> especially when attribute assertions are obtained from multiple 
>> attribute authorities.
>>
>> If the group has discussed this topic, what was your conclusion
>>
>> regards
>>
>> David
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

Hi David.

> [...]
> Yes, you can implement the hack you mention below, where you add a new 
> validity time attribute for every RC subject attribute, but a better 
> solution would to be to change the XML to allow optional validity times to 
> accompany each attribute, with default values of start now and never end. 
> This achieves backwards compatibility, but allows validity times to be 
> incorporated naturally with attribute values.

I agree with (what I think) Erik was suggesting, that the PEP/PIP is really
responsible for validity. From a policy evaluation point of view, the
PDP assumes that any input provided to evaluating a given policy is still
valid. A central piece of the XACML model is that the PDP is insulated
from the rest of the world: it assumes the attributes it's provided are
valid, and uses these to evaluate a policy.

Put another way, XACML defines the policy processing model, not the way
that interaction happens with the rest of the world. Yes, there is the
context schema which defines a standard, simple XACML Request that carries
only the core values that can drive evaluation. There's also SAML, which
should allow you to define validity periods or other constraints on any
attributes you need to provide. 

We could change the Request format to include validity periods, but what
effect would this have? It sounds to me like it would require the PDP
to consider validity of attribute values with each use, or at the point
in time that evaluation started, or some other metric. It would also
mean that we'd have to have some unified notion of time in a distributed
system, which is hard (well, provably impossible, but in practice there
are reasonable schemes for well-connected nodes).

I think what you really want is what SAML provides. The ability to put
constraints on attributes up to the point where some entity queries a
PDP for evaluation. I strongly believe that the PDP itself should not
have any role in determining the validity of attributes presented to it,
and that's really what we'd be talking aobut if the context schema
itself changed.

Erik - sorry for jumping in here :) Feel free to disagree..


seth

Hi Seth,

I agree with you completely. Thanks for jumping in. :-)

Regards,
Erik

Seth Proctor wrote:
> Hi David.
>
>   
>> [...]
>> Yes, you can implement the hack you mention below, where you add a new 
>> validity time attribute for every RC subject attribute, but a better 
>> solution would to be to change the XML to allow optional validity times to 
>> accompany each attribute, with default values of start now and never end. 
>> This achieves backwards compatibility, but allows validity times to be 
>> incorporated naturally with attribute values.
>>     
>
> I agree with (what I think) Erik was suggesting, that the PEP/PIP is really
> responsible for validity. From a policy evaluation point of view, the
> PDP assumes that any input provided to evaluating a given policy is still
> valid. A central piece of the XACML model is that the PDP is insulated
> from the rest of the world: it assumes the attributes it's provided are
> valid, and uses these to evaluate a policy.
>
> Put another way, XACML defines the policy processing model, not the way
> that interaction happens with the rest of the world. Yes, there is the
> context schema which defines a standard, simple XACML Request that carries
> only the core values that can drive evaluation. There's also SAML, which
> should allow you to define validity periods or other constraints on any
> attributes you need to provide. 
>
> We could change the Request format to include validity periods, but what
> effect would this have? It sounds to me like it would require the PDP
> to consider validity of attribute values with each use, or at the point
> in time that evaluation started, or some other metric. It would also
> mean that we'd have to have some unified notion of time in a distributed
> system, which is hard (well, provably impossible, but in practice there
> are reasonable schemes for well-connected nodes).
>
> I think what you really want is what SAML provides. The ability to put
> constraints on attributes up to the point where some entity queries a
> PDP for evaluation. I strongly believe that the PDP itself should not
> have any role in determining the validity of attributes presented to it,
> and that's really what we'd be talking aobut if the context schema
> itself changed.
>
> Erik - sorry for jumping in here :) Feel free to disagree..
>
>
> seth
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>