Below are the current issues for the XACML TC
Closed issues have been moved here: ClosedIssues
The status of each item is indicated with the following options:
OPEN No agreement on resolution.
PENDING Resolution has been reached, but is not reflected in the latest draft.
PENDING REVIEW Latest draft has been recently been updated to reflect resolution.
CLOSED Issue resolution is reflected in current draft or issue was dropped.
DEFERRED Issue is inactive but will be considered at a specific future time.
The target of the issue is indicated in the title as follows:
ADMIN Administrative Policy Profile (including administrative policy topics that affect 3.0 Core)
CORE XACML 3.0 Core
ERRATA XACML 2.0 Core errata
PROVISIONING Policy provisioning
SAML SAML 2.0 profile of XACML Version 2
WS-XACML Web Services Profile of XACML (WS-XACML)
12. CORE:More general conclusions
It has been proposed that the XACML language should be generalized to allow more complex decisions than yes/no. This could for instance mean that a rule which specifies encrypted access would override or be overridden by a rule which specifies unencrypted access, according to rules specified in the policy. There has also been discussion about imperative sequences as conclusions. Backwards compatibility with obligations is also an issue in this context.
The outstanding Use Cases are being addressed via modification of the current Obligation mechanism. http://wiki.oasis-open.org/xacml/DiscussionOnObligations
Erik and Bill are working on a proposal as of 10 May 2007.
36. PDP metadata
Should PDP metadata be made available in some form? Currently the following meta data has been identified: Attribute timing. Top level combining algorithm.
Action: Bill to provide a proposal (pending the outcome of #12).
A "placeholder" list has been created http://wiki.oasis-open.org/xacml/MetaData#preview to capture potential meta data of interest.
62. PROVISIONING:Policy provisioning interface
We have agreed (Issue#39) that the SAML Profile XACMLPolicyQuery will not attempt to provide a robust policy provisioning interface. The alternative proposal is that a separate policy provision interface be provided, possibly using SPML. Do we want such an interface?
Proposal outline at http://lists.oasis-open.org/archives/xacml/200702/msg00061.html. Discussion from March 2007 F2F in Minutes at end of first day at http://lists.oasis-open.org/archives/xacml/200703/msg00069.html
XACML Policy Distribution
New definition: Policy Cohort
A Policy Cohort is a set of policies (and/or policy sets) which are intended to be in force at a given time. Under XACML 3.0, a Policy Cohort may include both Administrative and Access Policies. However a Policy Cohort does not include just in time policies which are delivered with a decision request and in force only for the duration of that request. A Policy Cohort is typically tested as a unit and distributed as a unit.
A Policy Cohort has a name, which is a URI and it has members, which are zero or more policies or policy sets.
There is a Policy Administration Point (PAP) which holds all the policies for some domain. There are a number of Policy Decision Points (PDP) which retain in some local (typically non-volatile) storage one or more Policy Cohorts which are currently in effect or scheduled to be in effect in the future. A PAP will typically serve a number of PDPs. Conceivably a PDP may get its policies from several PAPs, however I am not aware of a motive for this usecase.
Multiple redundant PAPs may be deployed to improve availability. The means by which as PDP selects the PAP to obtain Policy Cohorts from will not be specified in the profile. Multiple PAPs or sets of PAPs may also be deployed to serve distinct sets of PDPs.
Each PAP must maintain configuration information assigning one of more Policy Cohorts to each PDP. If no Policy Cohorts have been assigned to a PDP, that PDP can not make access control decisions. For each mapping of a Cohort to a PDP, the PAP may maintain an effective date/time and an expiration date/time. If the expiration date/time is unspecified, the Cohort should go into effect immediately. If the expiration date/time is unspecified the Cohort is valid indefinitely.
This protocol is concerned only with the interaction between one PDP and one PAP. It is assumed that the PAP knows what Policy Cohorts should be in effect at different times at given PDP by some unspecified means. In a real deployment, this could be done in a number of ways. For example:
1. The UI which allows admins to creates policies also provides a mechanism which allows the admin to specify what PDPs should get what Cohorts at what times. This could be done individually or by grouping PDPs in some way.
2. The admin could be allowed to define some templates to apply to targets in policies in order to determine which PDPs get them. For example, each PDP might handle decisions with resource names that contained certain dns names. Say PDP1 gets policies pertaining to *.factory.example.com and PDP2 gets policies pertaining to *.marketing.example.com.
3. Policy identifiers could be chosen to indicate something about which PDP gets a given policy.
It is also possible that a PDP might have multiple distinct Policy Cohort which are in effect at the same time. In this case, the Cohort to evaluated must be determined for each policy decision by some means unspecified by the Profile. Typically the name of the Cohort would be specified implicitly or explicitly by the PEP.
It is assumed that each PDP has a unique identifier which the PAP knows in advance.
The protocol should make it easy to recover from failures of either participant or the communications link. Also in most cases work done prior to a failure should not have to be repeated. The protocol should make it possible for the PDP to determine that it has a complete and consistent set of policies.
It should be possible to stage Cohorts to go into effect at a future date.
The policies comprising a Cohort may not fit in a single message. However, it is assumed that no policy is so large that it can not be transmitted in a single message. In other words, it will never be necessary to split up a policy. Because it is likely that Policy Cohorts may often differ from each other by the addition or change of a few policies, it should only be necessary to transmit policies which the PDP does not already have.
All XACML Policies and Policy Sets contain an identifier. Different policies can contain the same identifier, but they will have different versions. The combination of Policy Identifier and version is assumed to be unique. For the purposes of this discussion the Id & version pair are called a Policy Id.
Although this Profile is intended for the distribution of XACML policies, it could be used with any sort of access control policies which can be carried in the envelope (i.e. represented in XML) and that have a unique identifier for each policy.
Two different protocols are defined, a push protocol (controlled by the PAP) and a pull protocol (controlled by the PDP). Both protocols have different advantages and disadvantages. It is expected that each will be used in different environments.
ISSUE: Would it be sufficient to use PAOS (reverse HTTP) with the push protocol instead of the pull protocol? It is not clear how practical the use of PAOS is when no data is transmitted for long periods of time. Of course, this objection could be met by defining some kind of heartbeat messages which would also allow for the determination of whether the parties are still functioning. However, this starts to move the scheme in the direction of a general purpose management protocol.
- Push Protocol
[This needs to be either dropped or updated to incorporate the notion of Cohorts.]
1 Req. (Optional) PDP -> PAP request policy update.
This message will be useful in cases such as a PDP first starting up.
2. PAP -> PDP request current policy list
This can be sent in response to an update request or as an unsolicited message. A PAP might initiate the request because an Administrator has updated the policies.
2. PDP -> PAP response with list of Policy Ids currently held by the PDP. Optionally the PDP can specify a maximum message size for policy updates.
PAP compares the policies held with the list of policies the PDP should hold.
3. PAP -> PDP Policy update batch.
The batch may begin with an optional effective date/time for the set of policies in the batch.
The batch contains two kinds of items:
A. Delete policy – specifies the Policy Id of a Policy to delete B. Add policy – contains Policy or Policy Set to add
(Batch mechanism TBD. Could use SPML batch function or WS-RM sequence.)
Each message in batch should be acknowledged. PDP should implement atomic update. No action should be taken until complete batch is received. Once batch is complete, the effective date/time should be checked. If it is missing or in the past, the update should be done immediately. Otherwise the update should be delayed until the effective date/time is reached.
In either case, when the update is performed, policy evaluation should cease. All deletes and adds should be applied. Then evaluation should resume.
- Pull Protocol
1. PDP -> PAP Request list of available Cohorts for specified PDP (default: this PDP)
2. PAP -> PDP Response returns list of Cohorts associated with specified PDP and their effective and expiration date/times
3. PDP -> PAP Request current policy list for specified Cohort
4. PAP -> PDP response – returns list of policy ids for specified Cohort, optionally a size estimate may be returned for each policy
PDP determines which Cohorts it wishes to obtain. For each Cohort it determines which policies it does not already have. It then requests the missing policies and constructs a local copy of the Cohort. It may make use of the size information to construct the queries.
5. PDP -> PAP Policy request – list of Policy Ids of policies to be returned
6. PAP -> PDP Policy response – Returns Policies and Policy Sets.
PAP is allowed to send subset of Policies requested. If a requested policy does not exist, an error must be returned identify the Policy in question. In this case, the PDP should go back to sending a request for the policy list for that Cohort.
PDP continues sending policy requests until all needed policies have been received. Then the effective date/time should be checked. If it is missing or in the past, the update should be done immediately. Otherwise the update should be delayed until the effective date/time is reached.
In either case, when the update is performed, the PDP stops evaluation, atomically adds new policies and deletes obsolete ones, then resumes policy evaluation.
66. Missing attributes may be underspecified
I did a somewhat detailed analysis of "Example two" in the core spec from the point of view of understanding how fine grained authorization (fga) (applying resource attrs to az decision) was implemented and came across a number of items that I think need to be addressed especially in potential interoperability situations. I will put all in one issue initially, we can decide if it needs to be broken out later.
While I recognize that the example itself is not intended to be perfect, it provides a convenient context for raising the following questions/issues, especially wrt fga.
- If this is a first request from a PEP, why is the PEP supplying patient-number on line 1056? This looks like a required attr to evaluate Rule 1 (line 1141), if the requestor is the patient, but this example the requestor is the physician.
- The physician-id is supplied in the request (line 1044), but the only rule it appears in is rule 3 (line 1522). This rule only allows "write" access (line 1507), so I expect this request would probably fail as it is currently set up. i.e. we would need to add a "read" action to rule 3 or add a physician-id test to rule 1.
Rule 1 requires a Subject attribute patient-number (line 1134) to match the patient-number in the requested resource record (line 1141). Presumably a <MissingAttributeDetail> could be returned, somehow identifying these 2 attributes to the PEP.
Rule 2 requires a patientDoB resource attr (line 1297), a parent-guardian-id subject attr (line 1363), and a parentGuardianId resource attr (line 1371). Similarly a <MissingAttributeDetail> could be returned requesting these.
- Assuming this to be the case, one question I have is how does the
<MissingAttributesDetail> tell the PEP whether the attributes that are missing should be resubmitted as part of the Subject or as part of the Resource? This info is provided in the Request from the xml structure, however, the <MissingAttributeDetail> does not have equivalent structure to make such distinctions.
The above is intended just to give an example of questions that occur for this particular example, but it is my opinion that it is symptomatic of a general problem of how PEPs are supposed to know how to construct the proper RequestContext necessary, in general, for complex scenarios that require substantive fga attrs.
In these more complex fga scenarios it is likely that <MissingAttributeDetail> will be typically needed to collect all the required attributes. Therefore, I believe some more robust mechanisms, possibly using MissingAttributeDetail as a good starting point will be needed to adequately define operation in this area.
In this context as well, it is likely that xpaths are probably not the way to go since they are only applicable to certain types of resources (xml-based) and those resource structures are likely to change in time, and these changes should not percolate into the enterprise Policy arena. Therefore, mechanisms such as vocabularies should be recommended usage here with the PEP being responsible for mapping the vocabulary item to the particular resource physical access path such as the xpath.
75. Defining an interface for closely coupled PEP/PDP
At the TC meeting on 11th Sept 2008 it was decided that this issue is best addressed by a separate profile, and that this issue is not on the critical path to 3.0.
This work is being pursued at the OpenAz Project. A number of TC members have contributed to it.
CHAMPIONS: Rich and Prateek
82. PRIVACY: error in FunctionId
The name of the function referred in the condition of the matching purpose rule is wrong. Instead of being "urn:oasis:names:tc:xacml:2.0:function:regexp-string-match" it's "urn:oasis:names:tc:xacml:2.0:function:string-regexp-match".
Reported on xacml-comment by Alejandro Cartas
WD 3 of privacy 3.0 contains a fix for this. No errata for 2.0 exists yet.
93. Issues Relating to the IP Address and DNS name Datatypes
The discussion began with a question on the xacml-dev list noting that there are no defined equality functions for these datatypes. It was confirmed that this is true and reference was made to the discussion of the issue at the time 3.0 was under development. This discussion noted that the comparison was not trivial and that the cited reference (RFC 2396) does not define a canonical form. It was not mentioned, but is discussed below, that currently any desired test can be performed by using string conversion and other functions to examine all or parts of the value in question.
These comments were posted by Hal to the xacml list on 9/26/13.
Information on all XACML datatypes appears in section A.2 of Appendix A of the core spec.
The IP Address, DNS name and XPath expression datatypes were added in XACML 2.0.
IP Address may contain a value which is either an IPv4 address or an IPv6. Implementations are expected to distinguish between them by their format. Both types consist of an address, optionally followed by a mask, optionally followed by a portrange.
IPv4 addresses are 32 bits in length and expressed in familiar dotted decimal format, e.g. 192.0.2.7 RFC 2396 is cited as the reference for the format. RFC 2396 has been obsoleted by RFC 3986, but I cannot see any effect on the definition.
IPv6 addresses are 128 bits in length. They are surrounded by “[“ and “]”. Generally the values are expressed as case insensitive hex digits with one to four digits (leading zeros are allowed) representing each 16 bit field with “:” separating each hex number. Any number of consecutive 16 bit groups with a value of zero can be compressed out by including “::” in the string. It is also legal to express the low order 32 bits in the IPv4 (dotted decimal) format. RFC 2732 is cited as the reference for the format. RFC 2396 has also been obsoleted by RFC 3986. RFC 3986 has been updated by RFC 6874 which adds some syntax to cover zones and future enhancements.
Mask is understood to mean Subnet Mask, which part of the address identifies the network+subnet and which part identifies the host. The mask is always a contiguous field of bits starting at the high order end. The one bits represent the network and subnet. The zero bits represent the host.
Unfortunately, none of the previously mentioned RFCs actually define the format to express the mask value. The mask value is preceded by a “/”. Two forms are used (at least for IPv4) either a dotted decimal value (e.g. /255.255.255.0) or the number of 1 bits. (/24) The former is called mask format and the latter is called CIDR format. I believe CIDR is more popular now, but I honestly have no idea what was meant in XACML 2.0 back in 2004. I believe for IPv6 only the CIDR form is used. Note that it is not necessary to know the Subnet Mask to compare two IP addresses (v4 or v6) for equality. Also note that IP in effect defines a canonical form for both, i.e. a 32 or 128 bit binary value in network order (order of transmission on the wire).
Obviously the mask format is more error prone in the sense that there are many illegal values, e.g. any non-contiguous set of one bits. However, even the CIDR form can produce invalid masks, depending on the IP address value. For example, 18.104.22.168/16 is illegal because the value is a Class C address which must have at least 24 bits of network address. It is not clear if XACML implementations are expected to check for this.
The portrange is a contiguous range of one or more ports. Port is a 16 bit field and zero is not allowed, so valid values go from 1 to 65535 inclusive. The syntax for this field is defined in the next subsection of A.2 “DNS name”. If present, portrange is preceded by a “:”. Briefly, examples of the allowed forms are: :80, :3000-3999, :-12345 or :65500-. Section A.2 says that this syntax is taken from Java socket permission.
DNS name is defined as a DNS host name followed by an optional portrange. RFC 2396 is cited again for syntax, with the addition that the leftmost component of the name may be “*” to indicate that any value will match. Clearly *.example.com will match www.example.com and mail.example.com and s1.mail.example.com will not. It is less clear to me whether *.mail.example.com matches mail.example.com. I believe the answer is no.
Portrange is the same as for IP Address and in fact is defined in the DNS name subsection.
Considering the two flavors of wildcard (DNS and portrange) I cannot think of any case where a wildcard would be the value of an attribute such as a Subject or Resource attribute. Therefore I believe these forms will only appear in as a constant in an <AttributeValue> element. Can anyone think of a counterexample?
The value of specifying the subnet mask depends on what operations we intend to support. More about this below.
The decision to include an optional portrange might be worth reconsidering. In my mind an IP address represents a node on a network. An IP address plus a port represents an endpoint. For policy purposes should we consider them as distinct? If so, do we need both of them or just one? Note that there are other ways to express an endpoint.
The DNS wildcarding has limited utility. Perhaps we should consider generalizing it or eliminating wildcarding entirely. For example, given the tendency to register related DNS names, people might want to use acme.* to include acme.com, acme.net, acme.org, etc.
This discussion began with a question about the absence of the equality functions ipAddress-equal and dnsName-equal. While these functions could ignore subnet mask, they probably would need to support portrange and DNS wildcards.
For those who need to test these values, note that the functions string-from-ipAddress and string-from-dnsName can be used in conjunction with various string functions and regexp functions to do just about any test you might want.
On the other hand, in addition to forcing policy authors to figure out how to implement what they want, this could also lead to subtle differences in evaluating these datatypes.
If it seems desirable to the TC to define comparison functions, the minimum would be to just define ipAddress-equal and dnsName-equal. If we decide to go beyond that we have a choice. We could either define comparisons against specific sub-elements, such as ipAddress-subnet-equal or simply define extraction functions such as ipAddress-subnet-to-integer. My preference is for the latter, but again, policy authors would be required to implement the subtleties of any comparisons.
To do list
Update references in Appendix A to current RFCs.
Either find a reference where CIDR format is defined or remove the claim that mask is defined elsewhere and define it ourselves. Also define full processing rules, including detecting invalid values. Alternatively drop subnet mask entirely.
Decide whether to support full IPv6 format as defined in RFC 6874 (& RFC 3986).
Decide whether portrange should be a part of a) IP address and b) DNS name. If so, decide if more generality is needed (lists of ports, non-contiguous ranges).
With respect to DNS wild carding decide if it should be dropped, generalized or left as is.
With respect to wildcarding in general, make explicit where wild card forms may appear.
Decide what if any additional comparison or extraction functions should be defined for these datatypes. Note it would be very useful to have some real world usecases here. What capabilities do firewalls and routers provide in these areas? A lot of the usecases I can think of would use URLs in practice.
94. Admin Profile: Problem with "delegated:" prefix
Steven Legg pointed out the the scheme of prefixing URIs with "urn:oasis:names:tc:xacml:3.0:attribute-category:delegated:" does not work for various reasons having to do with URI syntax. See Issue 97.
CHAMPIONS: Steven, Hal
95. Admin Profile: Handling XPath Category During Reduction
The procedure for administrative request generation in Section 4.5 of the XACML v3.0 Administration and Delegation Profile Version 1.0 Committee Specification 01 does not account for the category URI in XPathCategory XML attributes.
Resolved in CSD 04.
CHAMPIONS: Steven, Hal
96. Admin Profile: Multiple Decision Requests during reduction
A consequence of the algorithm in Section 4.5 for generating an administrative request is the possibility of the administrative request containing two <Attributes> elements with the same category, where that duplicated category has the prefix "urn:oasis:names:tc:xacml:3.0:attribute-category:delegated:".
Erik responded that the prefix is reserved for reduction calls and is not allowed in PEP calls.
Resolved in CSD 04.
CHAMPIONS: Steven, Hal
97. Admin Profile: Revise reduction algorithm
It is proposed that the administrative policy reduction algorithm be reworked to solve the policy prefixing issue, the interaction between the on-permit-apply-second combining algorithm and administrative policies. This would also generally make policy design easier. Related to Issue 94.
CHAMPIONS: Steven, Hal
98. Admin Profile: Reduction should use Extended Indeterminate Values
The reduction algorithm does not currently use the Extended Intermediate Values which were added to core later.
Resolved in CSD 04.
CHAMPIONS: Steven, Hal
99. Admin Profile: Combining Algorithm on-permit-apply-second limits policy delegation
The fact that the on-permit-apply-second combining rule restricts the number of child policies or policy sets to two means that where either child is a policy it must be a trusted policy (there is no room for authorizing administrative policies). This will have implications for access control on the policies themselves, which will vary between PAP implementations.
CHAMPIONS: Steven, Hal
100. Admin Profile: Mysterious requirements text in section 2.2
Section 2.2 - this text is here because the access-permitted function originally appeared in the A&D Profile. My suggestion is that we add the following text as a new paragraph at the end of the section.
Note: This usecase has been met by the Access Allowed function (urn:oasis:names:tc:xacml:3.0:function:access-permitted). That function was originally defined in this document. Its definition has been moved to [XACML] section A.3.16.
- Alternatively we could remove section 2.2 entirely or move it into section 6.2 - Alternative forms of delegation.
Resolved in CSD 04.
101. Admin Profile: Sections 4.12 & 8.5 should discuss Advice as well as Obligations
- Section 4.12 Obligations - This section normatively describes the handling of Obligations when Admin policies apply. We need to add similar text on Advice either here or in a parallel section.
- We should also add something to the discussion of Obligations covering Advice (section 8.5). Some of the considerations are the same and some are different.
Resolved in CSD 04.