http://permalink.gmane.org/gmane.ietf.plasma hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.plasma/159 <pre>More language and document nits fixed. Please review and send comments as I want to declare this document finished ASAP. -----Original Message----- From: internet-drafts&lt; at &gt;ietf.org [mailto:internet-drafts&lt; at &gt;ietf.org] Sent: Wednesday, June 12, 2013 2:27 PM To: Patrick Patterson; Jim Schaad; Trevor Freeman Subject: New Version Notification for draft-freeman-plasma-requirements-06.txt A new version of I-D, draft-freeman-plasma-requirements-06.txt has been successfully submitted by Trevor Freeman and posted to the IETF repository. Filename: draft-freeman-plasma-requirements Revision: 06 Title: Requirements for Message Access Control Creation date: 2013-06-12 Group: Individual Submission Number of pages: 57 URL: http://www.ietf.org/internet-drafts/draft-freeman-plasma-requirements-06.txt Status: http://datatracker.ietf.org/doc/draft-freeman-plasma-requirements Htmlized: http://tools.ietf.org/html/draft-freeman-plasma-requirements-06 Diff: http://www.ietf.org/rfcd</pre> Trevor Freeman 2013-06-12T21:29:39 http://permalink.gmane.org/gmane.ietf.plasma/158 <pre>Hi Folks, I am wrapping up work on the requirements draft. We need to move this along. Please let me have comments by 6/7. Thanks Trevor </pre> Trevor Freeman 2013-05-31T21:08:25 http://permalink.gmane.org/gmane.ietf.plasma/157 <pre>Hi All, I have posted a new requirements draft. The changes were all editorial nits, types etc. I believe we are close to closing this document and progressing to last call. Please review and send any feedback to so we can move this forward. Thanks Trevor -----Original Message----- From: i-d-announce-bounces&lt; at &gt;ietf.org [mailto:i-d-announce-bounces&lt; at &gt;ietf.org] On Behalf Of internet-drafts&lt; at &gt;ietf.org Sent: Monday, April 29, 2013 1:15 PM To: i-d-announce&lt; at &gt;ietf.org Subject: I-D Action: draft-freeman-plasma-requirements-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Message Access Control Author(s) : Trevor Freeman Jim Schaad Patrick Patterson Filename : draft-freeman-plasma-requirements-05.txt Pages : 60 Date : 2013-04-29 Abstract: There are many situations where organizations want to protect information with robust access control, either </pre> Trevor Freeman 2013-04-29T20:19:41 http://permalink.gmane.org/gmane.ietf.plasma/156 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond1< at >hushmail.com 2013-04-27T17:28:34 http://permalink.gmane.org/gmane.ietf.plasma/155 <pre>[Boldon James classification: UNMARKED EXTERNAL] Now we have our plasma client in demonstration form I performed some testing using an X.400 environment (STANAG 4406 to be precise). The P772 encoded Plasma message was sent / received but I was denied access trying to read the message. I tracked this down to the recipient I supplied in the GetCmsToken, rather than an SMTP address I have an X.400 O/R address, as below. &lt;Recipient&gt; &lt;Subject&gt;s=ab51;o=borland5;p=boldonjames;a= ;c=gb&lt;/Subject&gt; &lt;/Recipient&gt; I think we need another attribute to specify the type of 'Subject' we have supplied, something similar to below? &lt;Recipient&gt; &lt;Subject type="x400"&gt;s=ab51;o=borland5;p=boldonjames;a= ;c=gb&lt;/Subject&gt; &lt;/Recipient&gt; Alan. Alan Borland Boldon James Limited, a QinetiQ company Mobile: +44 (0)7810 556709 Direct: +44 (0)1270 507841 Switch: +44 (0)1270 507800 Email: alan.borland&lt; at &gt;boldonjames.com&lt;mailto:alan.borland&lt; at &gt;boldonjames.com&gt; Email (R): abborland&lt; at &gt;qinetiq.r.mil.uk&lt;mailt</pre> Alan Borland 2013-04-15T09:20:14 http://permalink.gmane.org/gmane.ietf.plasma/154 <pre>Update draft with a new way to handle encoding recipient infos. Please look at and make sure that it makes sense. Recommendations on other approaches should be discussed if you feel they are better than the one offered here. I am not emotionally attached to this encoding and we discussed a couple of alternatives before choosing this one. Jim </pre> Jim Schaad 2013-03-18T23:17:41 http://permalink.gmane.org/gmane.ietf.plasma/153 <pre>It is my believe you should perform the full path verification. If you don't then you have no confidence in any of the signed attributes associated with the signature such as the URL for the plasma server and thus go someplace you don't want to and start the plasma protocol. Jim From: plasma-bounces&lt; at &gt;ietf.org [mailto:plasma-bounces&lt; at &gt;ietf.org] On Behalf Of Alan Borland Sent: Wednesday, March 13, 2013 6:21 AM To: 'plasma&lt; at &gt;ietf.org' Subject: [plasma] Verifying the signature of the LockBox. [Boldon James classification: UNMARKED EXTERNAL] When we open a message we have to determine if the message is a traditional S/MIME message or a Plasma message. This is done by inspecting the CMS envelopedData layer looking for a Plasma LockBox. If the lockbox is found we verify the SignedData signature, but this got me thinking. Should we verify just the integrity of the signature itself or should we also perform a full certificate path validation as well? This would mean every user needs to trust a cert</pre> Jim Schaad 2013-03-13T12:44:07 http://permalink.gmane.org/gmane.ietf.plasma/152 <pre>[Boldon James classification: UNMARKED EXTERNAL] When we open a message we have to determine if the message is a traditional S/MIME message or a Plasma message. This is done by inspecting the CMS envelopedData layer looking for a Plasma LockBox. If the lockbox is found we verify the SignedData signature, but this got me thinking. Should we verify just the integrity of the signature itself or should we also perform a full certificate path validation as well? This would mean every user needs to trust a certificate from the Plasma Server (additional overhead - is this an issue?), but then if the Plasma Server is somehow compromised this would be a way of returning the error to the client. I couldn't decide either way, at the moment we're doing a full certificate path validation. Alan. Alan Borland Boldon James Limited, a QinetiQ company Mobile: +44 (0)7810 556709 Direct: +44 (0)1270 507841 Switch: +44 (0)1270 507800 Email: alan.borland&lt; at &gt;boldonjames.com&lt;mailto:alan.borland&lt; at &gt;</pre> Alan Borland 2013-03-13T10:21:20 http://permalink.gmane.org/gmane.ietf.plasma/151 <pre>Hi Jim An observation on the CMS draft is that you currently have the keyatt-eps-kek defined as a SignedData structure. The standard CMS signature creation and verification APIs expect to have the ContentInfo structure as the output\input data stream as defined by S/MIME defines. Net result when using these standard APIs is we end up manually removing the ContentInfo structure on creation and adding it on verification when processing the keyatt-eps-kek attribute. While not strictly necessary, it would streamline the code path if we were to use ContentInfo as we can skip the manual adding\removal of the ContentInfo structure. Trevor </pre> Trevor Freeman 2013-01-28T18:45:16 http://permalink.gmane.org/gmane.ietf.plasma/150 <pre>I have just submitted this draft. It has to do with how redacted documents would interact with Plasma servers. This document is partially there and partially a place holder. It does reflect my currently thinking, but that is subject to wild swings at the moment. If you really want to go ahead and read and comment. Jim </pre> Jim Schaad 2013-01-17T08:04:05 http://permalink.gmane.org/gmane.ietf.plasma/149 <pre>New document released. Moderate amounts of changes I think. Jim </pre> Jim Schaad 2013-01-12T01:17:24 http://permalink.gmane.org/gmane.ietf.plasma/148 <pre>New draft has finally be posted. Note - this draft has changed a great number of things, but has not yet addressed the options for policy questions.. I am still trying to get my mind around what needs to be done in all of the different locations and what it means for schema to try and get it all correct. Sorry I haven't gotten that far. I think that most of the issues people have raised other than that are included. The examples at the end are generated from my current code base and I believe reflect both the schema and the text of the draft. I have not however done a recent read through of all of the text to make sure that this is a correct statement. The schema should be correct as I did use a schema verify tool and came up with only one schema violation in the examples. That is the inclusion of an id attribute in the xacml:Request element. This is not legal according to the xacml schema. Jim </pre> Jim Schaad 2013-01-12T01:16:57 http://permalink.gmane.org/gmane.ietf.plasma/147 <pre>To answer Ed point. For the read (GetCMSKey) case, the email should be provided as a signed claim in a SAML token or via BAE, not as a self-asserted XACML attribute. This model holds where the requestor and the recipient are the same. This breaks down when they are different e.g. a server acting on behalf of a user. There we need some delegation claim coupled with the XACML attribute e.g. a signed claim that I am a sever for *.foo.com and an XACML attribute saying this instance of request id for alice&lt; at &gt;foo.com. This should be covered in the Plasma for MTA draft. -----Original Message----- From: Ed Simon [mailto:Ed.Simon&lt; at &gt;titus.com] Sent: Wednesday, January 2, 2013 3:04 PM To: Jim Schaad; Trevor Freeman; plasma&lt; at &gt;ietf.org Subject: RE: [plasma] Clarification of how client applications handle the LockBox in client in &lt;plasma:GetCMSToken&gt; elements If a XACML policy includes, inter alia, a rule that requiring a that only recipients may read an email, then the XACML will require either that the access subject be s</pre> Trevor Freeman 2013-01-09T19:40:35 http://permalink.gmane.org/gmane.ietf.plasma/146 <pre>For a DL that is not Plasma enhanced, it will result in the final recipient being unable to read the message as the Plasma server will refuse to grant access to the message. However this would assume that the DL is not security aware and thus it is not expanding CMS lockboxes to begin with. How the DL processes a message for which it cannot find a lockbox for itself is going to be DL dependent. It might just reject the message rather than distributing it. A Plasma server that knows a DL is not plasma enhanced could create a lockbox for the DL which is not externally policy enforced, thus the DL would process as today. For a DL that is Plasma enhanced, the DL will create a new Plasma recipient list and give it to the Plasma server. The Plasma server will then return either a new or an updated plasma CMS Recipient object to be placed in the message. A DL that is partly Plasma enhanced would get the key from the Plasma server, and then create new CMS lock boxes for all of the individuals on the DL </pre> Jim Schaad 2013-01-04T19:09:17 http://permalink.gmane.org/gmane.ietf.plasma/145 <pre>Ignoring the syntax of the "Recipient List" for the moment, but how will the recipient list mechanism work with distribution lists, especially those DLs expanded by the mail server? If on send I supply the plasma server "dl&lt; at &gt;xyz.com&lt;mailto:dl&lt; at &gt;xyz.com&gt;" as a &lt;Recipient&gt; and "fred&lt; at &gt;xyz.com" receives a copy of the message as a result of the DL expansion then will fred be able to read the message? Alan. Alan Borland Boldon James Limited, a QinetiQ company Mobile: +44 (0)7810 556709 Direct: +44 (0)1270 507841 Switch: +44 (0)1270 507800 Email: alan.borland&lt; at &gt;boldonjames.com&lt;mailto:alan.borland&lt; at &gt;boldonjames.com&gt; Email (R): abborland&lt; at &gt;qinetiq.r.mil.uk&lt;mailto:abborland&lt; at &gt;qinetiq.r.mil.uk&gt; Web: www.boldonjames.com&lt;x-excid://7DBF0000/pas:x-excid:/7DC00001/jmp:http:/www.boldonjames.com/&gt; Email classified by Boldon James Classifier - www.boldonjames.com&lt;http://www.boldonjames.com&gt; </pre> Alan Borland 2013-01-04T09:55:00 http://permalink.gmane.org/gmane.ietf.plasma/144 <pre> -----Original Message----- From: Jim Schaad [mailto:ietf&lt; at &gt;augustcellars.com] Sent: Thursday, January 3, 2013 11:36 AM To: Trevor Freeman; 'Ed Simon'; plasma&lt; at &gt;ietf.org Subject: RE: [plasma] Clarification of how client applications handle the LockBox in client in &lt;plasma:GetCMSToken&gt; elements to sender how a PIP required Plasma DN PIP. SAML The sender making the GetCMSKey call would never know if the set of recipients is required. Currently the set of policies on a message is not exposed to the client and thus the client would have no way of determining this. Remember we are talking here about reading a message not sending a message. [TF] The sender knows to include the recipient list because the policy in the role token has an option with the email address option set (plasma service section 7.2.2) On first contact, the client making the get message key request does not know if the email address attribute is required or not. It's a matter of local policy for the client to offer the email address up f</pre> Trevor Freeman 2013-01-03T21:55:28 http://permalink.gmane.org/gmane.ietf.plasma/143 <pre> to sender how a PIP required Plasma DN PIP. SAML The sender making the GetCMSKey call would never know if the set of recipients is required. Currently the set of policies on a message is not exposed to the client and thus the client would have no way of determining this. Remember we are talking here about reading a message not sending a message. Jim self- is a data it need to an value XACML, to subject, specified the subject to policy the IncludeInResult="false"&gt; format"&gt;asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj&lt;/AttributeV format"&gt;asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj&lt;/AttributeV ributes. format"&gt;asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj&lt;/AttributeV sender. list </pre> Jim Schaad 2013-01-03T19:35:33 http://permalink.gmane.org/gmane.ietf.plasma/142 <pre>What is your feelings about the other attributes that are currently transmitted in SAML statements that are going to be used as inputs to the decision making process? If the policy wants to check the company name, are you expecting the name to be supplied by the client and then somehow checked by the server or does the server extract it from the provided SAML statement that was used for authentication and input it into the policy decision system? I guess from my point of view, yes there will always be a PIP and the Plasma server can be the PIP Jim XACML, to subject, specified the subject to policy the IncludeInResult="false"&gt; format"&gt;asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj&lt;/AttributeV format"&gt;asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj&lt;/AttributeV ributes. format"&gt;asldkjfalskdjf32434534543dfjalkscxvkljzv2309080kjlkjlkj&lt;/AttributeV sender. list </pre> Jim Schaad 2013-01-03T19:34:26 http://permalink.gmane.org/gmane.ietf.plasma/141 <pre>Plasma is policy expression neutral. It is a mechanism to control access to data. The policy which controls the access which was defined by the sender may require a list of recipients for the data in questions. I don't see how a PIP would know who the recipients are for a message. The sender calling GetCMSKey would know if the set of recipients is required from the role token and can specify the list of 822 recipients to the Plasma server in the request. However a recipient calling GetMessageKey can only pass in attributes as SAML attributes. A Plasma server may use BAE to establish the email address of the requestor e.g. the request contains a DN and the plasma server used the DN to look up the email attribute from a PIP. Alternatively the Plasma server can reply with an indeterminate response requesting the email attribute in which case the client needs to get a SAML token with the requested attribute from its PIP. The defining distinction is that the list of recipients by the sender is self-asserted </pre> Trevor Freeman 2013-01-03T19:12:26 http://permalink.gmane.org/gmane.ietf.plasma/140 <pre>If a XACML policy includes, inter alia, a rule that requiring a that only recipients may read an email, then the XACML will require either that the access subject be specified in the XACML request (as I have said below) or that the identity of the access subject be accessible through a PIP; XACML, to my recollection, makes no automatic assumption that the authenticating party is the access subject party. If PLASMA is to require that the authenticating party be implicitly considered also as a XACML access subject, then PLASMA needs to be explicit about that and perhaps describe the means through which that is to be accomplished wrt XACML -- would it not? I do not see why it would be difficult for client apps to specify who the access-requesting email recipient is through XACML attributes in the GetCMSKey PLASMA request. That seems to me the easiest, most robust approach for both clients apps and policy servers. My preference is for PLASMA to say that email recipients are to be specified as XACML access subj</pre> Ed Simon 2013-01-02T23:04:27 http://permalink.gmane.org/gmane.ietf.plasma/139 <pre>It would appear to me that not allowing for the identities asserted during the process of doing the authentication not being a default set of access subject attributes would be incorrect and would make life much harder. For a simple policy one would still need to have a check that the access subject attribute asserted by the client is allowed for the set of known identities for the subject. While this makes sense if the policy is going to explicitly allow for impersonation, I think it is an unneeded burden on policy writers for the simplest of policies. Why would disagree with assuming that the party named is the same as the access subject unless a different access subject is explicitly stated by the client? Jim captured with necessarily using logically policy this a can could IncludeInResult="false"&gt; PolicyId="urn:example:policies:only-allow-these-recipients-to- user has AttributeId=""urn:oasis:names:tc:xacml:1.0:subject:subject- AttributeId=""urn:oasis:names:tc:xacml:1.0:subject:subject- AttributeId=</pre> Jim Schaad 2013-01-02T22:15:35 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.plasma