OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [XACML] Section 11. Security and Privacy


Title: [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