[OGSA-AUTHZ] Draft XACML/SAML Protocol Profile

[David Chadwick]

Valerio Venturi wrote:
> 
> Hi all,
> it looks to me that most of the doubts are not on integrity and 
> confidentiality in themselves, but about considering them more important 
> than authentication.
> Is assuring that something you don't know where is coming from wasn't 
> altered important? 

I would say it is not important in general. Since you dont know where
the message is coming from, then it is effectively coming from "Joe
Public" ie. anyone. Since it is coming from anyone, then it can
potentially contain anything. It really does not matter whether the
message has been altered or not if it can contain anything. One blob is
the same as another blob. The recipient has to evaluate the value of the
message based solely on its contents. Thus if the message is a policy,
and anyone can send a policy, then providing the syntax is correct, it
does not matter what the policy contents are or if the policy has been
altered or not during transfer since anyone could send me any valid policy.

The only instance I can think of that integrity and anonymity is
important is electronic voting systems, where the message contents have
a very limited set of values, and changing the value is important. But
even then, integrity on its own is not enough. The recipient has to know
that the sender was entitled to sent the message, so there has to be an
authenticity check as well as an integrity check. So authenticity is 
still important even if this case. Note however that authenticity does 
not mean identification. You may know that the vote is an authentic 
vote, but not the identity of the voter.

The case of policy requests you mentioned is even
> more critical than authz decision request. A malicious authz decision 
> allow access once, a malicious policy may allow access plenty of times.

agreed. This means that it is essential that the PDP check the
authenticity of the sent message, and integrity on its own is pointless
(as noted above)

regards

David

> What about having two SHOULD?
> It's more or less the same for confidentiality.
> 
> Valerio
> 
> 
> 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
>>>>       
>>
>>   
> 
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick at kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************