[plasma] Where is the PEP?

"Jim Schaad" <jimsch@nwlink.com> Thu, 08 December 2011 22:07 UTC

Return-Path: <jimsch@nwlink.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 02BAF21F8ADE for <plasma@ietfa.amsl.com>; Thu, 8 Dec 2011 14:07:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 UnCRIMGx8EBv for <plasma@ietfa.amsl.com>; Thu, 8 Dec 2011 14:07:58 -0800 (PST)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE3621F8AF5 for <plasma@ietf.org>; Thu, 8 Dec 2011 14:07:58 -0800 (PST)
Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id A91F738E6A for <plasma@ietf.org>; Thu, 8 Dec 2011 14:07:57 -0800 (PST)
From: "Jim Schaad" <jimsch@nwlink.com>
To: <plasma@ietf.org>
Date: Thu, 8 Dec 2011 14:07:27 -0800
Message-ID: <004401ccb5f5$c679d570$536d8050$@nwlink.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Acy18pICuzH8Oic9Q1CxM894eCe30w==
Content-Language: en-us
Subject: [plasma] Where is the PEP?
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: Thu, 08 Dec 2011 22:07:59 -0000

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