[plasma] Where is the PEP?
"Jim Schaad" <firstname.lastname@example.org> Thu, 08 December 2011 22:07 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BAF21F8ADE for <email@example.com>; Thu, 8 Dec 2011 14:07:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 ([184.108.40.206]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnCRIMGx8EBv for <firstname.lastname@example.org>; Thu, 8 Dec 2011 14:07:58 -0800 (PST)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [220.127.116.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE3621F8AF5 for <email@example.com>; Thu, 8 Dec 2011 14:07:58 -0800 (PST)
Received: from Tobias (exodus.augustcellars.com [18.104.22.168]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: firstname.lastname@example.org) by smtp4.pacifier.net (Postfix) with ESMTPSA id A91F738E6A for <email@example.com>; Thu, 8 Dec 2011 14:07:57 -0800 (PST)
From: "Jim Schaad" <firstname.lastname@example.org>
Date: Thu, 8 Dec 2011 14:07:27 -0800
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Microsoft Outlook 14.0
Subject: [plasma] Where is the PEP?
List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." <plasma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/plasma>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/plasma>, <mailto:firstname.lastname@example.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