[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] XACML September 26, 2002 Minutes
XACML Conference CallDate: Thursday, September 26, 2002 Time: 10:00 AM EDT Tel: 512-225-3050 Access Code: 65998
Summary
Action ItemsAnne Anderson to get comments to Tim Moses on the use of LDAP to store policies Anne Anderson to update the digital signature profile Anne Anderson to send a request to SAML for changes based on the XACML context. Will review list of proposed changes at next call. Tim Moses to make a separate document for the SAML profile Hal Lockhart and Konstantin Beznosov to produce an XACML primer
VotesAccepted minutes from 9/19/02 call
Proposed Agenda: 10:00-10:05 Roll Call and Agenda Review 11:00-12:00 Focus group discussion (if necessary)
Roll Call Ken Yagen, Crosslogix Hal Lockhart, Entegrity Carlisle Adams, Entrust Tim Moses, Entrust Don Flinn, Hitachi Konstantin Beznosov, Hitachi Michiharu Kudoh, IBM Simon Godik, Overxeer Polar Humenn, Self Anne Anderson, Sun Microsystems
Raw Minutes (taken by Ken Yagen)
Agenda Items Simon, Anne and Michiharu have extra comments to discuss. Will be added to agenda after technical change requests.
Vote to approve minutes approved
Action Items Michiharu Kudo to complete XPath specification Complete Anne Anderson to get comments to Tim Moses on the use of LDAP to store policies Still ongoing Anne Anderson to update the digital signature profile Still ongoing Anne Anderson to send a request to SAML for changes based on the XACML context Should be complete very soon. Next call is 10/1. Can we be ready for that call. Proposal would be that Anne would create list of proposed changes and our TC would review them. If we could come to agreement next week, it would be good to post to their mailing list. Carlisle will mention on 10/1 that they are coming soon and perhaps they can be discussed on the following SSTC call. Tim Moses to make a separate document for the SAML profile Ongoing Hal Lockhart and Konstantin Beznosov to produce an XACML primer Hal - been doing some work and will continue this week. Konstantin - waiting for feedback on outline. Some time allocated in agenda to discuss outline. Polar Humenn and Michiharu Kudo to post a summary of their proposal on the topic of "higher-order" functions Polar Humenn to post his proposal for using "higher-order" functions - ongoing Completed Carlisle has put together some text for truth table and they are included in v17. Please review text in v17.
Discussion of Functions 013 Draft Polar - believe it is complete Don't have corresponding X.500 and RFC name match as string-regex-match. Could double up functions and change order. Propose remove string-regex-match. Do not see a need for it. Order in X.500 and RFC arguments already changed so first argument is pattern matching. Tim will update v17 to remove string-regex-match and change order of X.500 and RFC arguments. In future asking if one X.500 dominate another one, may pick up a pattern from an attribute. But, don't see a use case right away.
Change Requests CR #8 Anne was to resubmit list of mandatory. Every single one are mandatory. Have question about date time add/subtract duration and year month add/subtract duration. It is hard to implement and tricky. Propose to keep them because have specification and it will be mandatory. The only non-mandatory function will be the three XPath functions.
CR #17 Resource Matching Change title to "NotApplicable Results"
"A result of "NotApplicable" means that the PDP did not have a Policy whose Target matched the information in the Request. In some security models, such as is common in many Web Servers, a result of "NotApplicable" is treated as equivalent to "Permit".
If "NotApplicable" is to be treated as "Permit", is it vital that the matching algorithms used by the Policy to match elements in the Request are closely aligned with the data syntax used by the applications that will be making the Request. A failure to match will be treated as "Permit", so an unintended failure may allow unintended access.
A common example of this is a Web Server. Commercial http responders permit a variety of syntaxes to be treated equivalently. The "%" can be used to represent characters by hex value. In the URL path "/../" provides multiple ways of specifying the same value. Multiple character sets may be permitted and, in some cases, the same printed character can be represented by different binary values. Unless the matching algorithm used by the Policy is sophisticated enough to catch these variations, unintended access may be allowed.
It is safe to treat "NotApplicable" as "Permit" ONLY in a closed environment where all applications that formulate a Request are closely aligned with the Policies used by the PDP. In a more open environment, where Requests may be received from applications that are not necessarily closely aligned with the Policies used by the PDP, it is HIGHLY RECOMMENDED that "NotApplicable" NOT be treated as "Permit" unless matching rules have been very carefully designed to match ALL possible applicable inputs, regardless of syntax or type variations."
Add something that our recommendation is to use default deny. Discussion of open vs. closed environment and what they mean. Loosely coupled? Gradations along a scale.
PEP may want to change handling of case based on number of PDP's available. Are recommending it handled in PDP as default deny. But in some cases appropriate to treat as permit.
Anne will update text and Tim will put in v17.
CR19 Inconsistent error behavior in combiner. Polar reviewed, agreed and revised the description. Tim will update v17 with new text.
CR47 Michiharu to submit DOM-equal specification. Completed in in 013 of functions
CR32 - In proposed text attribute name DataType on attribute selector in place. Simon under impression we were going to get rid of it. This is a typo. Change is applied in Schema i with no DataType
Michiharu - referencing the XPATH specification which is a work in standard. Need to reference a specific snapshot if that is a changing spec.
CR42 - CR47 approved
New issues from Simon/Anne/Michiharu delayed to after TC meeting
TOC for Primer Review Any comments or suggestions on proposed outline. Please send suggestions to Hal and Konstantin
Schedule V17 coming out later today. Please review for next week's meeting. Hope is to approve at 10/10 meeting. Then open review for one month before submit to Oasis. Need 3 attestations and statements aware of IP issues. Conformance tests need to be updated.
Regarding IP claims, If any claims, urge people not to wait until last minute to bring them up.
Attestations - Reuters has working version against current conformance test. Do we have two others? Sounds like at least two others will also be ready.
Carlisle to send updated schedule to Michiharu for website.
Dropped off - Carlisle take remaining minutes. [remaining minutes from Carlisle] Minutes for focus group (immediately after XACML TC call on Sept. 26, 2002).
Changes for v0.17 - Anne: - decimal-mod: motion to leave out of XACML 1.0 à approved - change from rfc822name and x500name to rfc822Name and x500Name à approved - new conformance section (updated to reflect above changes) - separating attributeValue from attributeIdentifier - ufs-path datatype should be a resource attribute instead - in Appendix B, two identifiers for authentication locality (ip address and dns name) should be subject attributes - B3: access subject category should be subject attribute - B5: rename to x500Name, rfc822Name; remove datatype ufs-path, gregorian, etc. - B7: last line ("add the LDAP attribute"): Simon will do this for v0.18 - B8: need to add resource-ufs-path, add action:action-id and action:action-namespace to a new section on action attributes, also add action:action-implied - B12: (after some discussion) get rid of B12, but add new section holding action-id and action-namespace
- Michiharu: - question regarding request #32, but this is reflected in schema "i" - section 6.27: change xpathVersion to XPathVersion à this will be reflected in v0.17 - AttributeSelector (p.49, Section 5.27): Michiharu suggested some text; Polar suggested some new text; Michiharu agreed; Polar will send to list.
- Simon: - XPathNamespace is in AttributeSelector; need it also in AttributeDesignator. Simon will post a discussion on this to the list. - there is currently no way to refer to the resource context using AttributeDesignator (i.e., without using the AttributeSelector). Could define a resource-content attribute and say that this is the same as the resource content element. Other options also exist. Simon will post a discussion on this to the list. - Simon applied the changes that Anne submitted - Simon asked: is the subject category name unique in the context? (Polar said "yes".) - Simon would like to have subject category included in SubjectAttributeDesignator (will go to the list with this) - Simon asked why we need the x500Name datatype (e.g., you already have a function that takes an x500 name). Some discussion by Simon, Polar, and Anne. Conclusion: selector does selection based on datatype implied by the function. Simon will take this to the list for further discussion.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC