[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [XACML] Section 11. Security and Privacy
Attached is a proposal for Section 11 Security and Privacy.
Do I need to add more detail?
Has the <ruledigest> element been dropped?
Thanks
James
<<section 11.txt>>
11. Security and Privacy (non-normative) This section identifies possible security and privacy vulnerabilities that should be considered when implementing an XACML based system. This section is strictly informative. It has been left to the implementers to assess whether these vulnerabilities apply to their environment and to select the appropriate safeguards. 11.1 Authentication Authentication here means the ability of a party to a transaction to determine the identity of the other party in the transaction. This authentication may be in one direction or it may be bilateral.1 Given the sensitive nature of access control system, it is important for a PEP to authenticate the identity of the PDP it is making authorization requests to. Otherwise, there is a risk that another process could provide false or invalid authorization decisions and comprise security of the access control system. It is equally important for a PDP to authenticate the identity of its clients and assess the level of trust to determine what, if any, sensitive data should be passed. One should keep in mind that even simple permit or deny responses could be exploited if someone was allowed to make unlimited requests to a PDP. May different techniques may be used to provide this authentication. Such as co-located code, private network, VPN or digital signatures. Authentication may also be done as part of the communication protocol used to exchange the authorization requests. In this case, the authentication may be performed at the message level or at the session level. 11.2 Confidentiality Confidentiality means that the contents of a message can be read only by the desired recipients and not anyone else who encounters the message while it is in transit.2 There are two areas where confidentiality should be considered. One is the confidentiality during transmission. The other is confidentiality within an XACML statement. 11.2.1 Communication Confidentiality All data within an access control system should be treated as confidential. This includes the XACML policy, the XACML requests and responses as well as any external data maybe referenced as part of the decision making process. If someone is able to eavesdrop on the communication they will understand under what instances access may be granted thus allowing them to impersonate a valid request. Any security concerns or requirements related to transmitting or exchanging XACML statements are outside the scope of the XACML standard. While it is often import to ensure that the integrity and confidentiality of XACML is maintained when they are exchanged between two parties, it is left to the implementers to determine the appropriate mechanisms for their environment 11.2.2 Statement Level Confidentiality In some case, an implementation may want to encrypt only parts of an XACML policy. For instance, a PRP only needs access to the target elements in order to find the appropriate rules. The other elements could be encrypted while they are stored in a repository. The XML Encryption Syntax and Processing standard from W3C can be used to encrypt the complete or parts of an XML document. This standard is recommend for use with XACML. It should go without saying that if repository is use to facilitate the communication of policy between the PAP and the PRR or between the PDP and the PIP that a secure repository should be used to store this sensitive data. 11.3 Policy Integrity The XACML policy, used by the PDP to evaluate the authorization requests, is the hart of system. There are two aspects of maintaining the integrity of the policy. One is to ensure that policy statements have not been altered since they were originally written or generated by the PAP. The other is to ensure that policy statements have not been inserted or deleted from the set of policies. In the many cases, this can be achieved by ensuring the integrity of the systems and implementing session level techniques to secure the communication between. The selection of the appropriate techniques been left to the implementers. However, when policy is distributed between organizations to be acted on at a later or when the policy travels with data, it would be useful to have digital signature of the policy included with the policy statements. In these cases, the XML Signature Syntax and Processing standard from W3C is recommended to be user with this standard. See section 8.3 for examples of using XML digital signatures with XACML. When digital signatures SHOULD only be used to ensure the integrity of the statements. Digital signatures SHOULD NOT be use as method of selecting or evaluating policy. The PDP could not request a rule base on who signed the rule or whether or not it had been signed. 11.4 Elements included by reference There is a risk that references and extensions contained with in a policy statement may have altered since the policy was originally created and thus changing the intent of the policy statement. For instance if a <policystatement> includes a rule by reference, there is no guarantee that rule has not been changed in-between the time that the policy was written and when it is being evaluated. A <ruledigest> element can be used to uniquely identify a rule. The <ruledigest> element contains a hash of the original rule. If he rule changed than the rule hash would also change. A digital signature of the source item could be included with the reference. This technique will allow the PDP to ensure that rule or extension had not been altered. Footnotes 1 - Security and Privacy Considerations for the OASIS Security Assertion Markup 3 Language (SAML) section 4.1 2 - Security and Privacy Considerations for the OASIS Security Assertion Markup 3 Language (SAML) section 4.2
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC