OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  Re: [xacml] Attribute predicate profile for SAML and XACML

    Posted 03-23-2011 13:32
    Gregory, You have invested considerable time on the draft document and produced good work. After reading the proposal, I would rather keep PEP logic to a minimum and move most of the functionality described to the context handler on the PDP side. From experience, the more "heavy lifting" is done by the service, the lighter the PEP is. It is in XACML's best interest to have light PEP's because adoption will be greater and faster. If the cost of entry for a PEP is too high, not as many PEPs will be developed. Changing the proposal to have the PDP/context handler do the attribute predicate request won't change the overall idea, but architecturally will make adoption more likely and less costly. I hope this makes sense. Doron Grinstein CEO BiTKOO On Mar 23, 2011, at 2:26 AM, "Gregory Neven" <nev@zurich.ibm.com> wrote: > Dear all, > > Please find attached a first draft of the attribute predicate profile > that we've been discussing during the telephone conferences. Looking > forward to your feedback! > > Best regards, > Gregory and Franz-Stefan > <2011-02 SAM+XACML Attribute Predicate Profiles.zip> > <SAML+XACML Attribute Predicate Profile.pdf> > --------------------------------------------------------------------- > 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


  • 2.  Re: [xacml] Attribute predicate profile for SAML and XACML

    Posted 03-23-2011 14:52
    Dear Doron, I agree, I imagine that anything being done by the PEP in the current document can just as well be done by the Context Handler. The Context Handler does see responses with missing attributes passing by, right? The same issue has previously been raised by Hal, in fact. Best, Greg On 3/23/2011 14:31, Doron Grinstein wrote: > Gregory, > > You have invested considerable time on the draft document and produced good work. After reading the proposal, I would rather keep PEP logic to a minimum and move most of the functionality described to the context handler on the PDP side. > > > From experience, the more "heavy lifting" is done by the service, the lighter the PEP is. > > It is in XACML's best interest to have light PEP's because adoption will be greater and faster. If the cost of entry for a PEP is too high, not as many PEPs will be developed. > > Changing the proposal to have the PDP/context handler do the attribute predicate request won't change the overall idea, but architecturally will make adoption more likely and less costly. > > I hope this makes sense. > > Doron Grinstein > CEO > BiTKOO > > > > On Mar 23, 2011, at 2:26 AM, "Gregory Neven"<nev@zurich.ibm.com> wrote: > >> Dear all, >> >> Please find attached a first draft of the attribute predicate profile >> that we've been discussing during the telephone conferences. Looking >> forward to your feedback! >> >> Best regards, >> Gregory and Franz-Stefan >> <2011-02 SAM+XACML Attribute Predicate Profiles.zip> >> <SAML+XACML Attribute Predicate Profile.pdf> >> --------------------------------------------------------------------- >> 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 > > > >


  • 3.  RE: [xacml] Attribute predicate profile for SAML and XACML

    Posted 03-23-2011 17:24
    Gregory, Excellent. We're on the same page! I had a thought regarding SECURITY when allowing attribute predicate expressions to be conveyed from a requestor to an attribute responder. The issue is fishing attacks (not phishing). What I mean is this: an attacker wants to find out secret information. This is information we're trying to protect by exposing only a Boolean result. However, repeated "fishing" requests can reveal the secret information. For example: A person's date of birth is Jan-15-1986. Repeated (programmed) attack similar to the example below (pseudo code) will reveal the exact information: Today-1day > 0 = true Today-2day > 0 = true . . Today-9199 > 0 = false // bingo - we can now calculate that the person's birthdate is Jan-15-1986 (Mar-23-2011 minus 9198days = Jan-15-1986) I am raising this point because if we do not address this from the start, we're going to expose users of this feature to potential data leakage risks. We should discuss, perhaps on Thursday ways to achieve the trusted attribute predicate request/response use case in this context. I have a couple of ideas such as a predicate pattern registration step which must be approved by the custodian of the attribute source; i.e. IsOver18Today() might be approved but ArbitraryOverAnAge() might be disapproved by the attribute custodian for the reason mentioned above. I welcome comments. Thanks, Doron Grinsteinš  CEOš  BiTKOO š 818-985-4700 Ext. 31 www.bitkoo.com


  • 4.  Re: [xacml] Attribute predicate profile for SAML and XACML

    Posted 03-24-2011 09:48
    Hi Doron, I agree that by querying many consecutive predicates, an attacker may still be able find out the exact value of attributes. I'm not so sure that restricting the class of permissible predicates is the best solution though, because if the class is too small, the approach with dedicated attributes isOver18, isOver21, etc. may be more attractive. Rather, I would imagine that the IDP implements some sort of fishing control, e.g., by imposing a limit on the number of queries per time period for the same user, or by requiring manual confirmation by the user before a predicate is asserted. We hinted at such mechanisms in step 3 of section 3.4 of the draft proposal when it says: "There may be situations where the SAML authority MAY not return an attribute predicate assertion, even though the XACML PDP does return Permit, for example, when additional policies apply, or when the subject does not give permission to return the queried assertion." Best, Greg On 3/23/2011 18:23, Doron Grinstein wrote: > Gregory, > > Excellent. We're on the same page! > > I had a thought regarding SECURITY when allowing attribute predicate expressions to be conveyed from a requestor to an attribute responder. The issue is fishing attacks (not phishing). What I mean is this: an attacker wants to find out secret information. This is information we're trying to protect by exposing only a Boolean result. However, repeated "fishing" requests can reveal the secret information. For example: > > A person's date of birth is Jan-15-1986. Repeated (programmed) attack similar to the example below (pseudo code) will reveal the exact information: > > Today-1day> 0 = true > Today-2day> 0 = true > . > . > Today-9199> 0 = false // bingo - we can now calculate that the person's birthdate is Jan-15-1986 (Mar-23-2011 minus 9198days = Jan-15-1986) > > I am raising this point because if we do not address this from the start, we're going to expose users of this feature to potential data leakage risks. > We should discuss, perhaps on Thursday ways to achieve the trusted attribute predicate request/response use case in this context. I have a couple of ideas such as a predicate pattern registration step which must be approved by the custodian of the attribute source; i.e. IsOver18Today() might be approved but ArbitraryOverAnAge() might be disapproved by the attribute custodian for the reason mentioned above. > > I welcome comments. Thanks, > > Doron Grinstein  CEO  BiTKOO  818-985-4700 Ext. 31 www.bitkoo.com > > >


  • 5.  RE: [xacml] Attribute predicate profile for SAML and XACML

    Posted 03-24-2011 15:00
    Security can sometimes be a game of cat and mouse. If we restrict the attribute predicate service to X number of requests/per-user/per-time-period, a denial of service attack surface becomes open (lock a target user out of being able to get attribute predicate responses). So to avoid a DoS-type attack the service provider should ideally authenticate, (also ideally using federation) the requests. That sounds like a good plan. So this isn't an issue anymore for the specification (aside from perhaps mentioning a guidance to implementers). It is an issue that should be addressed by implementers. I believe we're in agreement! Doron Grinsteinš  CEOš  BiTKOO š 818-985-4700 Ext. 31 www.bitkoo.com Book a meeting with me easily hereš: http://tungle.me/dorongrinstein