[OGSA-AUTHZ] Draft XACML/SAML Protocol Profile

[David Chadwick]

Hi Chad

comments on your integrity and confidentiality discussion

Chad La Joie wrote:

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

I dont believe this is the case. On the contrary, I think that if a
message is not authentic then it cannot be trusted. In other words,
authenticity is more important than integrity or confidentiality. A
message might not have been tampered with (integrity), but if the
recipient does not know who has sent it then it cannot be trusted. It
could be a genuine spoof message with integrity from an attacker. In the 
case of a message sent to a PDP, it could be a request for access sent 
by an attacker who is trying to discover the contents of the policy by 
bombarding the PDP will lots of requests. Unless the PDP knows that the 
message has come from the trusted PEP (i.e. authenticity) then the PDP 
should not respond.

Secondly confidentiality adds nothing with respect to trust. All
confidentiality provides is assurance that noone else read it. But that
does not confer trust in the message. A recipient can receive a message
from anyone that was encrypted to his public key (confidentiality), but
that does not confer trust in the message. Anyone could have sent it,
and the message could have integrity. But so what. The important thing
is to know who sent it.

In conclusion, authenticity provides both integrity and proof of who
sent it, and both of these are needed in order to trust the message.

Regards

David



> 
> 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.
> 
>> Finally, the restriction on lines 178--180 seems to contradict
>> sections 6.1 and 7 of the SAML-XACML profile.  Why restrict carte
>> blanche the proxying of the <saml:Assertion> by the requester?  Not
>> only does that contradict the SAML-XACML profile but it's clearly out
>> of scope for your use case.
> 
> There is no contradiction here and there is no proxying.  Instead, this 
> simply states that if an attribute authority provides attributes that 
> party can't then pass them around to others.  I know you're in favor of 
> this model, I am not.
> 
> For those that aren't subscribed to one of the many lists on which this 
> issue has been brought up, let me outline the basics.  These assertions 
> carry potentially sensitive information about a user.  Most attribute 
> authorities contain the ability to control the release of this 
> information on a per-party basis (i.e. A can see/request the sensitive 
> information but B may not).  A service which passed the information it 
> received onto another service circumvents the attribute authority and 
> its policies.
> 
> It's interesting that Tom brings up proxying.  I heard many a discussion 
> about this exact same problem, in regards to proxy credentials, at the 
> last two middleware design meetings I attended.  There are ways to 
> securely allow one service to impersonate a user to another service, but 
> it requires the active participation of the entity(ies) responsible for 
> the user.  Circumventing these entities may be much easier but it isn't 
> secure.
> 

-- 

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

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