[OGSA-AUTHZ] [Fwd: Re: Draft XACML/SAML Protocol Profile]

[Chad La Joie]

Sorry, didn't send this to the whole list.

-------- Original Message --------
Subject: Re: [OGSA-AUTHZ] Draft XACML/SAML Protocol Profile
Date: Wed, 12 Dec 2007 14:59:03 +0100
From: Chad La Joie <chad.lajoie at switch.ch>
Organization: SWITCH
To: David Chadwick <d.w.chadwick at kent.ac.uk>
References: <475418B0.5050003 at switch.ch>	 
<ea2af9bd0712091902p1b5547efv2d25c40e2b6b535c at mail.gmail.com>	 
<475CD07F.1050307 at switch.ch> 
<ea2af9bd0712100636l7f2c4ce4je88a6ecdd01194f2 at mail.gmail.com> 
<475D6EF7.504 at switch.ch> <475EBFCE.5030300 at kent.ac.uk>

No, no confusion.  I was referring to a very specific requirement,
integrity, which is orthagonal to authentication.  It happens that the
most common mechanism we use for confidentiality and integrity, SSL/TLS,
*may* also provide a means for authenticating the client as well.  It is
not required and it not doing does not change the integrity properties
of that mechanism.

David Chadwick wrote:
> Hi Chad
> 
> from your long response I do believe that you are confusing integrity 
> with authenticity. Can you tell me which integrity mechanism you are 
> thinking of that provides message integrity without any ability for the 
> recipient to determine who the sender is.
> 
> regards
> 
> David
> 
> Chad La Joie wrote:
>> 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


-- 
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