[OGSA-AUTHZ] Draft XACML/SAML Protocol Profile

[Chad La Joie]

Let me address confidentiality and integrity requirements separately.

XACML authorization decision requests *and* responses may carry XACML 
request contexts.  These contexts can contain sensitive information 
about individuals.  Such information can not be distinguished by 
requester/responder software.  The only way then to ensure the 
protection of such information is to always require that some form of 
confidentiality be in place.  This is also why the requester/responder 
is not allowed to forward assertion onto parties for which it was not 
intended.

Likewise the policy response may contain sensitive information, in most 
cases the sensitivity will likely stem from the ability to examine and 
exploit the policy under which the PDP will operate, but other issues 
may be present as well.  While we certainly hope that deployers won't 
have holes in their policies, the complexity of XACML makes it likely 
that such holes will occur.  Providing all the information necessary for 
an attacker to take advantage of such holes posses an unnecessary risk; 
a risk that is easily mitigated by confidentiality requirements.

Integrity is required within the authorization decision request so that 
an attacker can not manipulate the content of the request in order to 
produce a positive authorization decision.  While a PEP may be able to 
detect this if the XACML request context is returned by the PDP it is 
unlikely that the context will be returned in the response.  The 
authorization decision response needs to be protected because the 
response may simply be a "yes" or a "no".  The PEP has no way to 
determine if the message was changed in transit.  Also, note, that even 
if the responder did return the request context, allowing the PEP to 
verify that the request was not altered, such a check is meaningless 
without response integrity checking.

An integrity mechanism is required on a policy request to prevent a 
third party from intercepting the request and altering the policy 
requirements such that a more lax policy is returned.  It is required on 
the response to prevent that the policy itself from being altered.

Tom Scavo wrote:
> On Dec 10, 2007 12:37 AM, Chad La Joie <chad.lajoie at switch.ch> wrote:
>> Tom Scavo wrote:
>>> I'm sure you know this but if you change all the normative language
>>> regarding <saml:Issuer> from SHOULD to MUST, you essentially end up
>>> with the Assertion Query/Request Profile in section 6 of the SAML V2.0
>>> Profiles spec:
>>>
>>> http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
>> Yes, it's supposed to be very similar to the query/request profile.
>>
>>> So the obvious question is why did you change the language regarding
>>> <saml:Issuer>?
>> The responder needs to know who is making the request.
> 
> Well, this is straightforward query, so your profile can (and probably
> should) build on the Assertion Query/Request Profile (which requires
> <saml:Issuer>).  In that case, the profile reduces to little more than
> section 3.
> 
>>> Overall, your profile is a curious blend of more restrictive / less
>>> restrictive language with respect to the profiles it depends on.  The
>>> stated requirements on <saml:Issuer> are an example of the latter.
>>> The security requirements in section 3 seem to be an example of the
>>> former.  In particular, I find it odd that integrity and
>>> confidentiality are MUSTs, yet authentication is SHOULD.  Can you say
>>> a few words about that (beyond what's already written in the
>>> document)?
>> Why would you find it odd that security requests/responses require
>> integrity and confidentiality mechanisms?  They are required because not
>> doing them makes the request/response completely untrustwothy.
>>
>> In regards to authentication, this one I went back and forth on.  I
>> personally think the requester and responder should always be mutually
>> authenticated, but I could imagine cases where deployers had a more lax
>> view, especially on the policy request.  So, I just left it as a SHOULD
>> so that individual deployments could choose not to do it, if they wanted.
> 
> Section 6.1 of [SAMLSecure] addresses the security implications of the
> SAML SOAP Binding. In addition, section 3.1.2 of the SAML Bindings
> specification [SAMLBind] provides further security guidelines
> regarding SAML bindings.  Taken together, these security
> considerations adequately address this use case, I think.  Additional
> requirements with respect to integrity and confidentiality have not
> been justified.
> 
> Tom

-- 
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Security
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad.lajoie at switch.ch, http://www.switch.ch