Re: [plasma] Open-Environments

[Trevor Freeman <[e-mail]>]

Hi Jean-Paul,



The type of open I referred to was open world Assumption (http://en.wikipedia.org/wiki/Open_World_Assumption). This is essentially whether you consider your knowledge base to be complete (closed) or not (open).



If you look at the sequence of plasma tokens (role token, message token, read token) The role token is a closed world and the message and read tokens are open world. The role token has to be a closed world as it generates the finite set of policies the user can use. This collection of polices has also been referred to as a protection profile. It is configured by the administrator to meet the needs to the role. Subsequent tokens use an open world assumption, so that a PDEP can discover as required new policies. That said, the policy is in many ways no different to other attributes a PDP receives in that the PDEP has to have some policy around PAP it trusts. If a request is made to a PDEP which requires a policy from a PAP it does not trusted, then the PDEP would know to reply "don't know" just as it would if it could not reach the policy uri. The Plasma client can then try another PDEP.



Trevor



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Jean-Paul Buu-Sao
Sent: Friday, July 27, 2012 3:27 AM
To: [e-mail]
Subject: [plasma] Open-Environments



Thank you Patrick for forwarding the response from Trevor. Reading at them I see that there is one remaining comment that needs discussion (given that Richard Skedd has already created a thread on basic and Advanced Policies, that I will not re-iterate here). This is the question of Open Environments.



[JP] .... TSCP expected to see a workflow that could as well support an "open environment", whereas not all referenced policies are necessarily known by the local PDP/PAP ahead of time.

[TF] Since the PAP authors the policies and creates the policy reference, I don't understand a client can have a policy reference that a PAP does not know about so can you describe how this would occur.



[JP] In earlier discussions that we had in TSCP forums, you pushed forward the capability of PLASMA to operate in environments where not all policies are known, which you called "open environments". In this context, what I meant by " ... not all referenced policies are necessarily known by the local PDP/PAP ahead of time" is that the local PAP did not author such policy, which was authored by a non-local (remote) PAP in a different domain. Is the distinction between local PAP and remote PAP useful to the discussion? I think it is, as this difference potentially implies a difference on the trust model. I believe that, in order to support open environments, a dedicated trust model needs to be specified. Is it possible to discover a policy URI, and dereference it, without ensuring of the trustworthiness of the source? Those are some of the issues that, IMO, need to be called out in the document.



Thanks,

JP



-----Original Message-----

From: Patrick Patterson [mailto:[e-mail]]<mailto:[mailto:[e-mail]]>

Sent: Wednesday, July 25, 2012 17:08

To: Jean-Paul Buu-Sao

Cc: [e-mail]<mailto:[e-mail]>

Subject: Re: [plasma] Comments on Message Access Control Requirements Draft



The following message has been forwarded from Trevor, as he is still having difficulties posting to the list:



----- BEGIN FORWARDED MESSAGE -----



Hi Jean-Paul,



Just catching up from Holiday.



I have just posted a new draft of the requirements doc you may want to check out. We have has a lot of feedback on our terminology so this new draft has attempted to improve that area.



We have changed PEP to be a Decision Requestor to more clearly indicate it does not enforce decisions. We did not adopt the Access Requestor name from the XACML model as we have other types of decisions such as integrity policy decision requests.



PDP has changed to Policy Decision and Enforcement Point to emphasize in the Plasma model these functions are logically one. That does not preclude implementations from implementing them as separate entities but that implementations detail would not impact Plasma.



You should also read the technical drafts from the implantation details.



http://datatracker.ietf.org/doc/draft-schaad-plasma-cms/

http://datatracker.ietf.org/doc/draft-schaad-plasma-service/



More inline below



Trevor



-----Original Message-----

From: [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]><mailto:[mailto:[e-mail]]> On Behalf Of Jean-Paul Buu-Sao

Sent: Monday, July 23, 2012 1:25 AM

To: [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>

Subject: [plasma] Comments on Message Access Control Requirements Draft







Greetings,







Please find my comments on the PLASMA draft 01: http://tools.ietf.org/pdf/draft-freeman-plasma-requirements-01.pdf:







1) Policy Data Binding







Section 4.2.1:



"The chief strength of binding by names is once bound to the data the association with the policy travels with the data. The chief weakness in binding by name is it requires the reference to be strongly bound to the data [...] This model is choosing to use binding by name because we need to encrypt the data which means we will [be] impacting the storage format anyway which negates the main weakness of binding my name."



TSCP approves of the choice of "binding by name". Another chief strength that you did not quote, and which is key differentiator to TSCP, is to allow policy change, with no impact on the data. This requirement cannot be met with binding by value or by description.



[TF] Good Point will add this to the draft



The draft is silent on how the name would be expressed. Can it be any arbitrary identifier, which precise syntax and semantics could be defined by a community of interest defined profile?



[TF] If you read the plasma service draft you will see we use a URI. We believe that has sufficient flexibility to address the requirements you describe.







2) Closed versus Open environment



Section 4.4:



"(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



(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"



As stated the workflow implies a "closed environment". TSCP expected to see a workflow that could as well support an "open environment", whereas not all referenced policies are necessarily known by the local PDP/PAP ahead of time.



[TF] Since the PAP authors the policies and creates the policy reference, I don't understand a client can have a policy reference that a PAP does not know about so can you describe how this would occur.



There are a logical sequence of PDEPs in Plasma. These can be physically the same PDEP or they can be separate PDEPs.



*        The PDEP which generates the role token



*        The PDEP which generates the message token



*        The PDEP which generates the read token



Only the first PDEP needs prior knowledge of the policies which is necessary for it to generate the policy collection in the role token. All subsequent PDEPs can use the URI to discover the policies.



As a related topic, Policy Publication Point (PPP), lightly introduced in the Vocabulary section, is a good addition to [RFC3198] and [XACML-core]. In view of the support for "open environments", TSCP expected to see more requirements  on PPP.







3) Advanced Policies



Section 4.5.2:  "Advanced policy is intended to be used where one or more arbitrary policies are required on the content. It is intended to target more complex scenarios such as content with regulated information or content subject to other organization and contractual policies. The input set of attributes is defined by the policies and can be either primordial or derived attributes or both. Multiple policies have a logical relationship e.g. they can be <<AND or ORed together>>. <<It is not expected that all Plasma clients support advances policy>>."



[TF] The text was not intended to indicate only simple logical relationships would be expressed so I will change to say "AND and/or ORed together in an arbitrary combination". The technical draft uses a logic trees so already supports what you describe.







TSCP mandates a support for "advances policies".



[TF] I understand some communities of interest would require use of Advances Polices. However I don't want to burden every Plasma client implementation to support such policies. The basic policy set is aimed a simple set of scenarios where the Plasma client may well be bundled in at no charge so any additional complexity would be a tax. A premium client which supports advanced polices can then be purchased where there is business value in doing so e.g. a mandate from a community of interest such as TSCP.



A typical example is to support documents that must be simultaneously protected under an Export Control policy (e.g. ITAR Technical Assistance Agreement) and an Intellectual Property policy (e.g. Proprietary Information Exchange Agreement). In this case of multiple policies, TSCP requires that all the applicable policies are to be evaluated, with each one of the specified policy allowing the required access.



So this cannot just be a simple OR, as the Plasma draft states.











4) Policy Expression Language



The draft is silent on the positioning of PLASMA with Policy Expression Languages. Is there one in particular that PLASMA mandates (if so, which one), or is the specification agnostic (if so, what are the baseline requirements in terms of expressiveness)?





[TF] For the requirements I intend to be language neutral. We do intend to address PDAP-PAP interaction in a subsequent technical paper where the topic will have to be addressed. Some communities of interest have made significant investments in  XACML but it has not been universally adopted so plasma has a tradeoff between mandating a specific language to improve interoperability and alienating communities to do not use XACML. I don't know the right answer at this time but that answer does not impact the current work.  We do need to support language negotiation between PDEP and PAP so at a minimum so we can support communities of interest and also be forwards compatible.







Some organizations have developed and validated a broad set of policies, expressed in a Policy Expression Language of their choosing (e.g. XACML 2.0), and need to be able to reuse them.







Thanks,



Jean-Paul Buu-Sao, TSCP



---- END FORWARDED MESSAGE -----



---

Patrick Patterson

President and Chief PKI Architect

Carillon Information Security Inc.

http://www.carillon.ca



tel: [phone]

mobile: [phone]

fax: [phone]











_______________________________________________

plasma mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/plasma