Hi Jim,
Here is my take. There does not seem consensus over the exact role of a PEP, and maybe that is by design. If you look at XACML v3 core it cites rfc3189 as a normative reference. Both XACML and 3198 define the PEP role yet the definitions are not completely aligned. 3198 defies a PEP as:- Policy enforcement: The execution of a policy decision. Policy Enforcement Point (PEP): A logical entity that enforces policy decisions (See also "policy enforcement") You can merge the two statements to be more concise i.e. A PEP is a logical entity responsible for the execution of policy decisions. This s a fairly general purpose, any policy model. XACML is more restrictive. It defines PEP as:- The system entity that performs access control by making decision requests and enforcing authorization decisions. This is very much an access control policy model definition. It also implies a trust model. The policy decision requested by both the Plasma and XACML PEP is "can the client\user access the specified message/data". In order to execute the permitted decision in a Plasma PEP, we need both the encrypted data and the decryption key. This is distinct from an XACML PEP which has access to the clear text data and can simply relase the data. The critical difference between the two is the trust model. In Plasma we do not unconditionally trust the PEP with the clear txt data; plasma performs an access check first, and then releases the clear text data to the PEP. XACML trusts the PEP with all clear text data regardless of any access check. The decision request is the same for both PEPs, but the execution of the decision is different because of the different trust models. Trevor -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jim Schaad Sent: Thursday, December 08, 2011 2:07 PM To: [email protected] Subject: [plasma] Where is the PEP? At the last IETF meeting, Trevor and I got together to try and hammer out the skeleton of what the XML protocols would look like for the plasma work. During this process we found that the WS-Trust work did not appear to have a good way of returning error information for such items as "missing attribute". However the XACML documents did have this type of structure and are designed for working between the PEP and PDP so they seemed to be a good place to base some of the work from. In the process of doing this, one of the things that was going to be highly desired was to be able to carry a SAML Assertion as part of the request from the PEP to the PDP. I found the follow document "SAML 2.0 Profile of XACML, v2.0" http://docs.oasis-open.org/xacml/3.0/xacml-profile-saml2.0-v2-spec-cs-01-en. pdf which game a "simple" method of mapping the attributes of a SAML statement onto a XACML request. The expectation is that this would be done by the PEP (or some entity between the PEP and the PDP) that is highly trusted as it does the mapping and validates the signatures on the SAML assertion. This expectation of trust does not map well onto the current Plasma mode and got me thinking about the question of where the PEP and PDP boundaries really lie. I think there may be some level of confusion in the future that we should at least consider today. The problem as I see it is that there are two different things that access is being granted to and this is not explicitly spelled out in the model. Access is being granted to the E-Mail message: This is where we are thinking of the PEP as living today. That is we are trying to get access to the e-mail message. Access is being granted to the KEK: This is where the real PEP/PDP are living. In this case the PEP is not a fully trusted entity and does not actually grant or deny access to the KEK value. For our purposes the PEP to get access to the KEK value is actually living with (or near) the PDP and is the plasma server itself. This is the think that gets a grant statement and then send the resource back to the e-mail client's PDP. The dichotomy is of issue mostly in terms of how trusted the PEP is and therefore what things can be done. The issue in this case is what level of trust can we place in the entity we are calling the PEP (none) and therefore what level of validation of attributes needs to be setup for the items that would normally be placed in the XACML Attribute structures. The PEP would normally be permitted to assert that an attribute was correct. In our case this is not a true statement. This will affect how we look at using both XACML and SAML. I.e. we probably don't want to use the mapping specified above, but we may want to look at creating a new way to place an entire SAML Assertion in an XACML Attribute and leave the PDP to re-distribute it around. Comments? Jim _______________________________________________ plasma mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/plasma
_______________________________________________ plasma mailing list [email protected] https://www.ietf.org/mailman/listinfo/plasma
