Greetings, Please find below some additional comments focused on 4.3 Content Creation and 4.4 Content Consumption, workflows:
Section 4.3: Content Creation Workflow "The content creation PEP is configured with the set PIP's and PDP's it trusts" (p.39) This assumes that the PEP is directly associated to all (possibly remote) applicable PDPs. This will not scale with a large number of applicable PDPs. Instead, would you consider a local PDP proxy, which will then be able to cache information related to remote PDPs when applicable? "The content creation PEP summits a request to all the trusted PDPs for the set of roles it allows for the subject. The subject is authenticated and authorized for the roles via attributes from the PIP. The PIP attributes can be obtained by the PDP either via front-end (related to the PDP from the PIP via the subject) or back-end (direct exchange between the PDP and the PIP) processing"(p. 39) See comment above about scalability and availability. The result of the request can be locally cached by a local proxy, caching would be impossible otherwise. Also, authorization is not always solely based upon subject attributes that represent set of roles. "The content creation PEP receives a list of roles the PDP can [be] configured for the subject" (p.39) The same comment as above applies, regarding roles. Additionally the Content Creation PEP must not evaluate the attributes for authorization decision, as this is the role of the PDP. So why should it care receiving the list of roles that can be configured for the subject? "The PEP submits a request for the policy collection for each role. Additional attributes may be required from the PIP to authorize the release of the BCPC token" (p. 39) Not necessarily optimal: the list of "roles" may be very large. Why would the PEP request the associated policy collection on such a large list, before even considering the intention of the subject? Shouldn't the PEP rather wait for the subject to express its intention, that is: explicitly specify the subset of the policies that are to be applied to the content to be created? The general feedback on this workflow is that the Content Creation PEP "bootstrap" steps 1 to 4 provided for illustration only, and are implementation dependent. Also, BCPC is not defined in the document "(i) The user creates the new content (ii) The user select the appropriate business context for the content, then selects one or more policies applicable to the content (iii) The PEP encrypts the content with one or more locally generated CEKs"(p. 40) Once policies are selected, I'd like to suggest that the standard XACML flow applies: the PEP asks authorization decision to the PDP, who may return "Permit" with obligation to encrypt the content; encryption is a policy decision, not a unilateral decision from the PEP. "(iv) The PEP submits the CEK, the set of requires policies to be applied and the hash of the encrypted content to the PDP. The CEK can be a raw key or a CEK key encrypted by a KEK if the user does not want the PDP to have the ability to access the plain text data. (v) The PDP generates the encrypted metadata which contains the list of policies and the CEKs. The metadata is encrypted by the PDP for itself. The PDP includes a URL for itself and the hash of the protected content as authenticated attributes then signs the encrypted metadata." (p. 40) This, IMO, goes well beyond the responsibility of the PEP (as defined in the draft and in XACML core spec). This should be either the Creation Content PEP, or better a specific Data Encryption Point, to be defined. "(vi) The PDP returns the metadata to the PEP (vii) The PEP attaches the PDP metadata to the protected content and distributes the content." (p. 40) The general comments about this workflow are: a) The standard XACML flow can be preserved between the Content Creation PEP and the PDP: content encryption would then be a policy obligation expressed by the PDP (as part of a permit decision) and enforced by the PEP b) In case of required content encryption, the Content Creation PEP would carry on encryption by perhaps interacting with a Data Encryption Point, which can execute the steps related to encryption as described in the draft. Section 4.4. Content Consumption Workflow "(A) The PEP verifies the certificate in the signed metadata then determines via local policy if it want to process the protected information based on the identity of the PDP" (p. 40) This implies a policy decision, which has to be taken by a local PDP. Also note that there are potentially multiple policies, hence potentially multiple associated PDPs. This strengthen the case for a local PDP proxy that needs to take this decision "(B) The PEP verifies the signature on the metadata token and the binding to the encrypted data by hashing the encrypted information and comparing it to the authenticated attribute in the metadata" (p. 40) Surely this is not the role of the PEP but of a Data Decryption Point that the PEP must be associated with "(C) The PEP forwards the signed metadata and requests a read token from the PDP using the location in the authenticated attribute in the metadata" (p. 40) The PEP role is overloaded. I suggest that it is the local PDP which will request these read token from the remote PDPs "(D) The PDP decrypts the metadata, de-references the policy pointers and determines the set of access rules based on the policy published by the PAP. The PDP then determines the set of subject attributes it needs to evaluate the access rules. The PDP can the use PIP is has relationships with to query attributers about the subject. The list of attributes the PDP is missing is then returned to the PEP" (p. 40) "(F) Once the PDP has a complete set of attributes, and the attribute values match those required under the access policy, the PDP releases the CEK to the PEP along with a TTL which defines how long the PEP can use the CEK before it must discard the CEK and reapply for access." (p. 40) The PDP role is overloaded with encryption tasks that may be better handled by encryption points (useful additions to the XACML architecture) Thanks, Jean-Paul Buu-Sao, TSCP -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Hal Lockhart Sent: Monday, June 11, 2012 17:53 To: [email protected] Subject: [plasma] Comments from OASIS XACML TC on Message Access Control Requirements Draft In response to Requirements for Message Access Control (http://tools.ietf.org/pdf/draft-freeman-plasma-requirements-01.pdf) the OASIS XACML Technical Committee has agreed to submit the attached comments. The public link to this document is: https://www.oasis-open.org/committees/download.php/46049/Proposed%20response%20to%20Plasma%20v1-3.docx Hal Lockhart Bill Parducci Co-chairs OASIS XACML TC _______________________________________________ plasma mailing list [email protected] https://www.ietf.org/mailman/listinfo/plasma
