Re: [plasma] Basic and Advanced Policies

[Trevor Freeman <[e-mail]>]

Hi Richard,

 

The whole question of interoperability with policy parameters is a bit of a

Pandora box issue. To work, both the policy expression language and the

client need to support the parameter in question. 

 

It's an accurate observation that some Domain Specific Languages (DSLs) like

XACML have limitations in the area of policy parameters. General Purpose

Languages (GPLs) like C# don't have that limitation. Given the only policies

today which will mandate a parameter are the basic policies, it would be

trivial to author the basic policy in C#. Where a DSL supports parameters,

then the policy authored by they DSL can likewise support parameters.

Hopefully DSLs that don't support parameters would respond to the need so

can be used by Plasma in the future. However support by the language is not

the only issue.  

 

It would be hard to get client support without bounding the issues of the

allowed set of possible policy parameters. In many ways this is the harder

problem. We could try to dynamically discover the set of parameters a client

supports but this would open up a complex matrix of where polices did, or

did not work for any organization to manage. A simpler approach may be to

simply define by plasma client version the set of parameters the client

needs to support.  You still have a matrix of what policies works where but

it's a more bounded and manageable matrix. However for this approach to work

we need rev the standard and to come to consensus around a set of parameters

to incorporate into a client. Jury is out on what the right thing to do is

here. 

 

Replay and forwarding do rains some extra considerations. With basic policy,
I think to be consistent with S/MIME todays there is any boundary on
recipients other than maintaining the policy itself.  If you send requiring
level 2 authentication or better for recipients then any forwarded or reply
message should have the same policy. 

 

For policies without a recipient list the problem is more complex

 

The high order bit seems not what operations are possible but what latitude
does the recipient have to change the message policy.  If you have a subject
who otherwise would be allowed to see some content, who was omitted from the
original message, it seems counter intuitive to suggest the message cannot
be forwarded to them or they be added to a reply. Likewise if the
information I add to my reply or forward requires me to apply my policy to
my new data, then I should by default also be allowed to append a policy.
Equably it would seem a privileged action to expand the set of possible
readers, but you may want to allow it in some situations. 

 

Trevor

 

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

From: Skedd, Richard (UK) [mailto:[e-mail]] 

Sent: Wednesday, August 15, 2012 10:02 AM

To: Trevor Freeman; [e-mail]

Subject: RE: Basic and Advanced Policies

 

Thanks Trevor, please see some further thoughts in response to your two

comments below:

 

Addressee Only Policy

 

OK, understood, the PDP could use the information in the message to process

this policy, which will work where the PDP is capable of using a

parameterized policy (e.g. asserted e-mail address matches one of the
message

recipients e-mail addresses) rather than an explicit policy (e.g. asserted

e-mail address is one of list of values).  My understanding is that

parameters are not well supported by today's policy expression languages or

my policy enforcement applications.  If this is correct then it would be

useful to flag these requirements.

 

IMHO it would be good to use "Addressee Only Policy" or similar as the name

for this capability rather than the less precise "Basic Policy".

 

Replying to and forwarding messages could introduce new addressees and new

sensitivities.  There must be some definition of an addressee's scope for

action, possibly with options that are selectable by the sender.  Can an

addressee reply, reply to all, reply and include new addressees, forward ?

If, for example, the addressee replies to some of the original addressees

with a message that is also covered by the "Addressee Only" policy then does

the PDP use the recipient e-mail addresses for the reply or the original

message to control access ?  It would be useful to have the "Addressee Only"

policy documented for use cases other than just reading of the initial

message.

 

Baseline Client Functionality

 

>From what you say I understand that you are proposing that all clients will

be capable of enforcing the "Addressee Only Policy".  This means that they

have the functionality to:

 

1.  Retrieve multiple attributes about the requester (e-mail address,

identity assurance level) from at least one attribute authority

2.  Retrieve multiple attributes from the message/resource (applicable

policies, allowed e-mail addresses, required minimum identity assurance

level)

3.  Identify the rule sets to use implement the applicable policies

(Addressee Only with potentially specified limitations on recipient actions)

4.  Retrieve the appropriate rule sets, I assume not "hardwired" in the

client, although it may be cached for performance

5.  Process the rule sets which will be expressed using attributes,

parameters, comparison operators and logical operators (requester e-mail

address is a member of allowed e-mail addresses AND identity assurance level

>= required minimum identity assurance level)

6.  Permit/deny the requested action (Any, or reply to all recipients,

forward to new address)

 

At this level a baseline client which is capable of enforcing the "Addressee

Only Policy" will also meet all the functional requirements for an

"Arbitrary Single Policy".  Whether the user is a subscriber to the

necessary attribute authorities and policy authorities to be able to

exercise this functionality is another matter.  Again we need to understand

the intent of PLASMA for "Arbitrary Single Policy" use cases beyond read the

initial message.  Is a baseline client expected to be able to generate a

reply which may also be subject to the "Addressee Only Policy" or an

additional "Arbitrary Single Policy" ?

 

Regards

 

Richard Skedd

Strategy Manager - Office of the CIO

T:    [phone] (vnet 7658 8034)

M:    [phone] (vnet 777118260)

 

BAE Systems plc

Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK

Registered in England & Wales No: 1470151

 

 

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

From: Trevor Freeman [mailto:[e-mail]] 

Sent: 14 August 2012 19:26

To: Skedd, Richard (UK); [e-mail]

Subject: RE: Basic and Advanced Policies

 

----------------------! WARNING ! ---------------------- This message

originates from outside our organisation, either from an external partner or

from the internet.

Keep this in mind if you answer this message.

Follow the 'Report Suspicious Emails' link on IT matters for instructions on

reporting suspicious email messages.

--------------------------------------------------------

 

Hi Richard,

 

The intent of basic policy is the former i.e. to replicate existing S/MIME

functionality where the sender designates the list of authorized recipients.

In the Plasma case basic policy has a parameter which is the list of

recipients. The policy defines "anybody presenting an authenticated email

attribute where the attribute value matches one of the named recipients and

the level of assurance of the identity matches that required under the

policy would pass the policy". We don't need a new policy ID per recipients

list. 

 

I agree we need a baseline of common functionality for the client. Technical

all of the policy complexity is hidden from the client so a recipient is

unaware how many polices were applied to a message. Policy complexity would

only be manifest by the set of attributes the policy can request. In the

advanced case, the set of attributes is unbounded. What do we put into the

economy version of the Plasma client? The base client would likely have to

exist as part of an email service as part of their baseline offering at very

little margin in order to be pervasive.  Current proposal is to put enough

in to support the Personal to Addressee scenario. We should be able to build

into the base profile, recognition that you need the full featured version

securely e.g. no "please clink on this link and install my latest malware"

kind of experience. The proliferation of app stores and marketplaces will

help here. 

 

Trevor 

 

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

From: 

[RWS] 

 

[e-mail] [mailto:[e-mail]] On Behalf Of Skedd,

Richard (UK)

Sent: Friday, July 27, 2012 2:35 AM

To: [e-mail]

Subject: [plasma] Basic and Advanced Policies

 

A follow-up on comments by Trevor Freeman, kindly forwarded by Patrick

Patterson, and Jean-Paul Buu-Sao on the requirements for Basic v Advanced

Policies and the update of have draft-freeman-plasma-requirements-02 which

now states that:

 

4.6.1 Basic Policy

 

Basic policy is intended to be universally usable by using a small fixed set

of attributes. For example, basic policy is intended to be equivalent to

sending encrypted Email with S/MIME today.  It is a simple policy that

authenticated recipients of the Email get access to the message.  Its

intended target is simple scenarios involving consumers and small businesses

who are using public PIP which issue a limited set of attributes. It is

expected that all Plasma clients and commercial IdP would be capable of

supporting basic policy due to their simplicity and basic attribute set.

 

4.6.2 Advanced Policy

 

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.

 

In my view the terminology proposed does not reflect the capabilities

described nor do the capabilities described align with typical use cases.

 

If the intent of the "Basic Policy" is actually to replicate S/MIME

functionality then it is an "Object Access Control List Policy".  The

mechanism of S/MIME combined with the list of addressees effectively limits

access to the addressees but without originator control over further use of

the content by the addressees.  This is a valuable approach as it deals with

the "Personal to Addressee" and similar use cases by giving the originator

bespoke control over distribution.  However, it does not involve a "Basic

Policy" as a new policy with a unique ACL will need to be generated for

every message.

 

If the intent of the "Basic Policy" is to address " simple scenarios

involving consumers and small businesses who are using public PIPs which

issue a limited set of attributes" then this must require the ability to

create rules which include logical operators (AND, OR etc) to process the

attributes.  eg "Customer for Product X AND Customer for Product Y",

"Customer for Product X OR Retailer of Product X".  This is effectively

addressing the requirements of an object linked to a "Single Policy" rather

than a "Basic Policy".

 

Dealing with "Single Policies" rather than multiple policies would then be

consistent with the statement that "Advanced Policy is intended to be used

where one or more arbitrary policies are required on the content".  Which

raises a further question, is the ability to cope with content which

references multiple policies an optional capability?  The paper refers to a

e-mail thread in which the addition of information also adds additional

policies.  Surely this scenario occurs everywhere all the time.  Any request

response scenario could involve data that is sensitive to each party eg "Can

you quote to supply X, My price for X is $$$" or "Can you come to a meeting

about X, No because I need to do Y".

 

It thus seems to me that whilst there are different policy usage scenarios

(Bespoke, Single, Multiple) these must all be core PLASMA capabilities

supported by all PLASMA clients rather than add-ons for specialist

applications by some communities of interest.

 

Regards

 

Richard Skedd

Strategy Manager - Office of the CIO

T:    [phone] (vnet 7658 8034)

M:    [phone] (vnet 777118260)

 

BAE Systems plc

Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK Registered in

England & Wales No: 1470151

 

 

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

From: [e-mail] [mailto:[e-mail]] On Behalf Of

Patrick Patterson

Sent: 25 July 2012 16:08

To: Jean-Paul Buu-Sao

Cc: [e-mail]

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

 

----------------------! WARNING ! ---------------------- This message

originates from outside our organisation, either from an external partner or

from the internet.

Keep this in mind if you answer this message.

Follow the 'Report Suspicious Emails' link on IT matters for instructions on

reporting suspicious email messages.

--------------------------------------------------------

 

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]]<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]>

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]

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