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