[plasma] Basic and Advanced Policies

"Skedd, Richard (UK)" <Richard.Skedd@baesystems.com> Fri, 27 July 2012 09:34 UTC

Return-Path: <Richard.Skedd@baesystems.com>
X-Original-To: plasma@ietfa.amsl.com
Delivered-To: plasma@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049B721F85F6 for <plasma@ietfa.amsl.com>; Fri, 27 Jul 2012 02:34:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level:
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ix5z7n6I1ZXK for <plasma@ietfa.amsl.com>; Fri, 27 Jul 2012 02:34:51 -0700 (PDT)
Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 6F89621F85F2 for <plasma@ietf.org>; Fri, 27 Jul 2012 02:34:50 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.77,666,1336345200"; d="p7s'?scan'208"; a="259460351"
Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 27 Jul 2012 10:34:49 +0100
Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q6R9YlGw029603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <plasma@ietf.org>; Fri, 27 Jul 2012 10:34:49 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.170]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0309.002; Fri, 27 Jul 2012 10:34:48 +0100
From: "Skedd, Richard (UK)" <Richard.Skedd@baesystems.com>
To: "plasma@ietf.org" <plasma@ietf.org>
Thread-Topic: Basic and Advanced Policies
Thread-Index: Ac1qfYzEE77XKwr7QLmya2XkWVhuzA==
Date: Fri, 27 Jul 2012 09:34:47 +0000
Message-ID: <BF916BD8800FFC49B59E5B0D8A1D212E24ECEC60@GLKXM0002V.GREENLNK.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.109.62.6]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0041_01CD6BE3.713A8060"
MIME-Version: 1.0
Subject: [plasma] Basic and Advanced Policies
X-BeenThere: plasma@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." <plasma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/plasma>, <mailto:plasma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/plasma>
List-Post: <mailto:plasma@ietf.org>
List-Help: <mailto:plasma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/plasma>, <mailto:plasma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jul 2012 09:34:53 -0000

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:    +44 117 918 8034 (vnet 7658 8034)
M:    +44 780 171 8260 (vnet 777118260)

BAE Systems plc
Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK
Registered in England & Wales No: 1470151


-----Original Message-----
From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of
Patrick Patterson
Sent: 25 July 2012 16:08
To: Jean-Paul Buu-Sao
Cc: plasma@ietf.org
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: plasma-bounces@ietf.org<mailto:plasma-bounces@ietf.org>
[mailto:plasma-bounces@ietf.org]<mailto:[mailto:plasma-bounces@ietf.org]> On
Behalf Of Jean-Paul Buu-Sao
Sent: Monday, July 23, 2012 1:25 AM
To: plasma@ietf.org<mailto:plasma@ietf.org>
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: +1 514 485 0789
mobile: +1 514 994 8699
fax: +1 450 424 9559





_______________________________________________
plasma mailing list
plasma@ietf.org
https://www.ietf.org/mailman/listinfo/plasma