From scott.c.fitch@lmco.com Sat Dec 3 18:21:17 2011 Return-Path: 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 A6C901F0C35 for ; Sat, 3 Dec 2011 18:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.72 X-Spam-Level: X-Spam-Status: No, score=-6.72 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ROLEX=3.878, HTML_MESSAGE=0.001, 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 6X2iQJgzXS3E for ; Sat, 3 Dec 2011 18:21:14 -0800 (PST) Received: from mailfo02.lmco.com (mailfo02.lmco.com [192.35.35.12]) by ietfa.amsl.com (Postfix) with ESMTP id DF8F221F8D10 for ; Sat, 3 Dec 2011 18:21:13 -0800 (PST) Received: from emss07g01.ems.lmco.com ([166.29.2.16]) by mailfo02.lmco.com (8.14.3/8.14.3) with ESMTP id pB42L8De002656; Sun, 4 Dec 2011 02:21:08 GMT Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31805) id <0LVN00601QJ5S5@lmco.com>; Sun, 04 Dec 2011 02:21:05 +0000 (GMT) Received: from HDXHTPN6.us.lmco.com ([158.188.83.13]) by lmco.com (PMDF V6.4 #31805) with ESMTP id <0LVN002NJQJ0M1@lmco.com>; Sun, 04 Dec 2011 02:21:00 +0000 (GMT) Received: from HDXDSP11.us.lmco.com ([fe80::c04a:c222:3486:3e3]) by HDXHTPN6.us.lmco.com ([fe80::1db3:a00c:a3c9:9df6%14]) with mapi id 14.01.0355.002; Sat, 03 Dec 2011 19:21:00 -0700 Date: Sun, 04 Dec 2011 02:20:58 +0000 From: "Fitch, Scott C" In-reply-to: X-Originating-IP: [158.188.95.10] To: Trevor Freeman , "plasma@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_uhqKlULc896n1TmotPYXCw)" Content-language: en-US Thread-Topic: Delegation scenario Thread-Index: AcyTPvJuZ6lTqdglQi+54J/v8g5UNQCWpMtQByQ9/MA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: References: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110, 1.0.211, 0.0.0000 definitions=2011-12-04_01:2011-12-02, 2011-12-04, 1970-01-01 signatures=0 Subject: Re: [plasma] Delegation scenario X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 02:21:17 -0000 --Boundary_(ID_uhqKlULc896n1TmotPYXCw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Trevor, et al- Sorry it took me so long to reply on this. Anyway, I can see two scenarios, and two ways that a Plasma implementation could met the requirements. The first delegation scenario is a persistent delegation such as between a Boss and an Administrative assistant. In this case, the Admin gets to read (most of) the Boss's email. The second scenario is temporary delegation, such as assigning a role to an individual while on vacation. In this case, the delegate only has access to the messages while the delegator is on vacation. As for ways the Plasma addresses this, it can either be done through the access rules (e.g., Boss's assigned Administrative Assistant is allowed to read company proprietary information, but not personal information) or through the assertions provided to the PDP at access request (e.g., Delegate has Role X, which meets the criteria for reading the message). In both cases, these approaches are greatly preferable to PKI-based S/MIME, which usually involves sharing private keys, removing all granularity for access. Let me know if that's enough to go on. -Scott Scott Fitch Cyber Architect scott.c.fitch@lmco.com From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Friday, October 28, 2011 1:48 PM To: Fitch, Scott C; plasma@ietf.org Subject: EXTERNAL: RE: Delegation scenario That is a good observation. If you give a brief outline on how you see a scenario changing for delegation and I will incorporate that into the next version. From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Fitch, Scott C Sent: Tuesday, October 25, 2011 10:57 AM To: plasma@ietf.org Subject: [plasma] Delegation scenario Plasma also opens up the opportunity to support delegation in a much more sustainable and elegant manner than current PKI-based S/MIME. I'd like to see that called out as a scenario in Section 3. Others have similar thoughts? -Scott --Boundary_(ID_uhqKlULc896n1TmotPYXCw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Trevor, et al-

                Sorry it took me so long to reply on this. Anyway, I can see two scenarios, and two ways that a Plasma implementation could met the requirements.

 

The first delegation scenario is a persistent delegation such as between a Boss and an Administrative assistant. In this case, the Admin gets to read (most of) the Boss’s email.

 

The second scenario is temporary delegation, such as assigning a role to an individual while on vacation. In this case, the delegate only has access to the messages while the delegator is on vacation.

 

As for ways the Plasma addresses this, it can either be done through the access rules (e.g., Boss’s assigned Administrative Assistant is allowed to read company proprietary information, but not personal information) or through the assertions provided to the PDP at access request (e.g., Delegate has Role X, which meets the criteria for reading the message).

 

In both cases, these approaches are greatly preferable to PKI-based S/MIME, which usually involves sharing private keys, removing all granularity for access.

 

Let me know if that’s enough to go on.

 

                -Scott

 

Scott Fitch

Cyber Architect

scott.c.fitch@lmco.com

 

From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com]
Sent: Friday, October 28, 2011 1:48 PM
To: Fitch, Scott C; plasma@ietf.org
Subject: EXTERNAL: RE: Delegation scenario

 

That is a good observation. If you give a brief outline on how you see a scenario changing for delegation and I will incorporate that into the next version.

 

From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Fitch, Scott C
Sent: Tuesday, October 25, 2011 10:57 AM
To: plasma@ietf.org
Subject: [plasma] Delegation scenario

 

Plasma also opens up the opportunity to support delegation in a much more sustainable and elegant manner than current PKI-based S/MIME. I’d like to see that called out as a scenario in Section 3. Others have similar thoughts?

 

                -Scott

--Boundary_(ID_uhqKlULc896n1TmotPYXCw)-- From Richard.Skedd@baesystems.com Tue Dec 6 05:56:08 2011 Return-Path: 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 8110A21F8B3F for ; Tue, 6 Dec 2011 05:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FRT_ROLEX=3.878, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] 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 7TPsFmH0v5lp for ; Tue, 6 Dec 2011 05:56:05 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8706B21F8B3D for ; Tue, 6 Dec 2011 05:56:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,306,1320624000"; d="scan'208,217";a="174797255" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 06 Dec 2011 13:56:03 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id pB6Du26M015812; Tue, 6 Dec 2011 13:56:03 GMT Received: from GLKMS2105.GREENLNK.NET ([10.15.184.96]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Dec 2011 13:56:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCB41E.CA6893E4" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 6 Dec 2011 13:56:02 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Delegation scenario thread-index: AcyTPvJuZ6lTqdglQi+54J/v8g5UNQCWpMtQByQ9/MAAe836IA== From: "Skedd, Richard (UK)" To: "Fitch, Scott C" , "Trevor Freeman" , X-OriginalArrivalTime: 06 Dec 2011 13:56:02.0804 (UTC) FILETIME=[CA9A7340:01CCB41E] Subject: Re: [plasma] Delegation scenario X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 13:56:08 -0000 ------_=_NextPart_001_01CCB41E.CA6893E4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Plasma certainly provides an opportunity to take an approach that would be preferable to that which we end up doing today. A few thoughts to add to Scott's: Although we typically describe this as a delegation scenario, I would describe it as one case of a shared mailbox scenario. There are a number of these but I don't think that the relationships between the members of the team using the shared mailbox are important for plasma. This could equally apply to members of a design team, a family or a medical practice. Messages will arrive in the mailbox. Access to an individual message is dependent upon the sensitivity of the message and the privileges of the user accessing the mailbox. Privileges are assigned for a period which may itself be dependent on certain conditions. There are many examples: - Executive - has an assistant that is authorised for company proprietary whilst she holds her position but not personal - Manager - has a colleague that is authorised for project x information whilst the worker is on vacation but not project y - Engineer - is one of five on the team that are authorised for proprietary information from company a whilst they hold their positions but not company b - Father - has two daughters that are authorised for notices about school events whilst they are students at the school but not an appointment with a doctor - Doctor - has a number of nurses that are authorised for messages about the doctor's patients whilst they are on duty and assigned to work with the doctor but not practice management information The impact of this capability on how we choose to establish and manage e-mail addresses is another thread of discussion ... 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 From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Fitch, Scott C Sent: 04 December 2011 02:21 To: Trevor Freeman; plasma@ietf.org Subject: Re: [plasma] Delegation scenario *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Trevor, et al- Sorry it took me so long to reply on this. Anyway, I can see two scenarios, and two ways that a Plasma implementation could met the requirements. The first delegation scenario is a persistent delegation such as between a Boss and an Administrative assistant. In this case, the Admin gets to read (most of) the Boss's email. The second scenario is temporary delegation, such as assigning a role to an individual while on vacation. In this case, the delegate only has access to the messages while the delegator is on vacation. As for ways the Plasma addresses this, it can either be done through the access rules (e.g., Boss's assigned Administrative Assistant is allowed to read company proprietary information, but not personal information) or through the assertions provided to the PDP at access request (e.g., Delegate has Role X, which meets the criteria for reading the message). In both cases, these approaches are greatly preferable to PKI-based S/MIME, which usually involves sharing private keys, removing all granularity for access. Let me know if that's enough to go on. -Scott Scott Fitch Cyber Architect scott.c.fitch@lmco.com From: Trevor Freeman [mailto:trevorf@exchange.microsoft.com] Sent: Friday, October 28, 2011 1:48 PM To: Fitch, Scott C; plasma@ietf.org Subject: EXTERNAL: RE: Delegation scenario That is a good observation. If you give a brief outline on how you see a scenario changing for delegation and I will incorporate that into the next version. From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Fitch, Scott C Sent: Tuesday, October 25, 2011 10:57 AM To: plasma@ietf.org Subject: [plasma] Delegation scenario Plasma also opens up the opportunity to support delegation in a much more sustainable and elegant manner than current PKI-based S/MIME. I'd like to see that called out as a scenario in Section 3. Others have similar thoughts? -Scott ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** ------_=_NextPart_001_01CCB41E.CA6893E4 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Plasma cert= ainly provides an opportunity to take an approach that would be preferable = to that which we end up doing today.  A few thoughts to add to Scott&#= 8217;s:

 

Although we typically describe this as a = delegation scenario, I would describe it as one case of a shared mailbox sc= enario.  There are a number of these but I don’t think that the = relationships between the members of the team using the shared mailbox are = important for plasma.  This could equally apply to members of a design= team, a family or a medical practice.  Messages will arrive in the ma= ilbox.  Access to an individual message is dependent upon the sensitiv= ity of the message and the privileges of the user accessing the mailbox.&nb= sp; Privileges are assigned for a period which may itself be dependent on c= ertain conditions.

&nbs= p;

There are many examples:<= /o:p>

 

-       = Executive – has an assistant that is aut= horised for company proprietary whilst she holds her position but not perso= nal

-  &= nbsp;    Manager –= has a colleague that is authorised for project x information whilst the wo= rker is on vacation but not project y

-       Engineer – is one of five on the team that are auth= orised for proprietary information from company a whilst they hold their po= sitions but not company b

= -       Father – has two daughters that are authorised for notices abou= t school events whilst they are students at the school but not an appointme= nt with a doctor

-&= nbsp;      Doc= tor – has a number of nurses that are authorised for messages about t= he doctor’s patients whilst they are on duty and assigned to work wit= h the doctor but not practice management information

=

 

= The impact of this capability on how we choose to establish and manage= e-mail addresses is another thread of discussion …=

 

Regards

&= nbsp;

Richard Skedd

Strategy Manager - Office of the CIO=

T:    +44 117 918= 8034 (vnet 7658 8034)

M:&nb= sp;   +44 780 171 8260 (vnet 777118260)

 

BAE Systems plc

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

Registered in England & Wales No: 1470151

 

From: plasma-bounces@iet= f.org [mailto:plasma-bounces@ietf.org] On Behalf Of Fitch, Scott CSent: 04 December 2011 02:21
To: Trevor Freeman; plasma@= ietf.org
Subject: Re: [plasma] Delegation scenario

 

                    *= ** WARNING ***

  This message has originated outside your organ= isation,
  either from an external partner or the Global Internet. =
      Keep this in mind if you answer this message.

Trevor, et al-

       &= nbsp;        Sorry it took me so long to= reply on this. Anyway, I can see two scenarios, and two ways that a Plasma= implementation could met the requirements.

 

The first delegat= ion scenario is a persistent delegation such as between a Boss and an Admin= istrative assistant. In this case, the Admin gets to read (most of) the Bos= s’s email.

 <= /span>

The second scenario is temporary delegation, s= uch as assigning a role to an individual while on vacation. In this case, t= he delegate only has access to the messages while the delegator is on vacat= ion.

 

As for ways the Plasma addresses this, it can either be do= ne through the access rules (e.g., Boss’s assigned Administrative Ass= istant is allowed to read company proprietary information, but not personal= information) or through the assertions provided to the PDP at access reque= st (e.g., Delegate has Role X, which meets the criteria for reading the mes= sage).

 

In both cases, these approaches are greatly preferable= to PKI-based S/MIME, which usually involves sharing private keys, removing= all granularity for access.

&= nbsp;

Let me know if that’s enough= to go on.

 =

        &nbs= p;       -Scott

 

Scott Fitch

Cyber Architect

scott.c.fitch@lmco.com

=

 

From: Trevor Freeman [mailto:trevorf@exchang= e.microsoft.com]
Sent: Friday, October 28, 2011 1:48 PM
To= : Fitch, Scott C; plasma@ietf.org
Subject: EXTERNAL: RE: Dele= gation scenario

 

That is a good observation. If you give a= brief outline on how you see a scenario changing for delegation and I will= incorporate that into the next version.

 

From:= plasma-bounces@ietf.org [mailto:plasma-bounce= s@ietf.org] On Behalf Of Fitch, Scott C
Sent: Tuesday,= October 25, 2011 10:57 AM
To: plasma@ietf.org
Subject: [plasma] Delegation scenario

&nb= sp;

Plasma also opens up the opportunity to support de= legation in a much more sustainable and elegant manner than current PKI-bas= ed S/MIME. I’d like to see that called out as a scenario in Section 3= . Others have similar thoughts?

<= span lang=3DEN-US style=3D'font-family:"Cambria","serif"'> =

          = ;      -Scott


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

------_=_NextPart_001_01CCB41E.CA6893E4-- From jimsch@nwlink.com Tue Dec 6 18:51:18 2011 Return-Path: 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 BC68721F8BBE for ; Tue, 6 Dec 2011 18:51:18 -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 83Egl6N8xyzI for ; Tue, 6 Dec 2011 18:51:18 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 45D2821F8BBB for ; Tue, 6 Dec 2011 18:51:18 -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 smtp3.pacifier.net (Postfix) with ESMTPSA id A778B38EA6; Tue, 6 Dec 2011 18:50:34 -0800 (PST) From: "Jim Schaad" To: "'Fitch, Scott C'" , References: In-Reply-To: Date: Tue, 6 Dec 2011 18:50:00 -0800 Message-ID: <000101ccb48b$06819070$1384b150$@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: AQG7xHPKDhsfd7m54voQYQhsijmmXpXxeaAg Content-Language: en-us Subject: Re: [plasma] S/MIME Capabilities X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 02:51:18 -0000 Just to be clear, you are suggesting that an attribute defined by which a sender says "I understand Plasma" just like there is one which says I understand inner binary. Recipients could then store this attribute as part of the senders capabilities. This is totally trivial and yes we should do it. I assume that this would just be a "binary" value - I do or do not support it. If a new version of Plasma ever comes into existence then a new attribute with a different OID value would be created. There is no need to talk about algorithms or advance vs basic here. Jim > -----Original Message----- > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On > Behalf Of Fitch, Scott C > Sent: Tuesday, October 25, 2011 12:00 PM > To: plasma@ietf.org > Subject: [plasma] S/MIME Capabilities > > Section 5.2.1 notes the backwards compatibility requirement with existing > S/MIME where a sender can create recipient info structures for recipients it > can discover keys for. > > Should there be an equivalent mechanism to indicate a sender's support for > plasma, similar to the way that S/MIME indicates current capabilities? This > could be helpful, particularly when sending messages with Advanced Policies. > > -Scott > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma From scott.c.fitch@lmco.com Wed Dec 7 05:31:49 2011 Return-Path: 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 AB13221F8B11 for ; Wed, 7 Dec 2011 05:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.659 X-Spam-Level: X-Spam-Status: No, score=-8.659 tagged_above=-999 required=5 tests=[AWL=1.940, BAYES_00=-2.599, 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 tCRhMBelltdK for ; Wed, 7 Dec 2011 05:31:49 -0800 (PST) Received: from mailfo02.lmco.com (mailfo02.lmco.com [192.35.35.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1431821F8B02 for ; Wed, 7 Dec 2011 05:31:48 -0800 (PST) Received: from emss07g01.ems.lmco.com ([166.29.2.16]) by mailfo02.lmco.com (8.14.3/8.14.3) with ESMTP id pB7DVlZS009346; Wed, 7 Dec 2011 13:31:47 GMT Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.4 #31805) id <0LVU00H015KWIV@lmco.com>; Wed, 07 Dec 2011 13:31:44 +0000 (GMT) Received: from HDXHTPN7.us.lmco.com ([158.188.83.14]) by lmco.com (PMDF V6.4 #31805) with ESMTP id <0LVU00H1Q5KR4F@lmco.com>; Wed, 07 Dec 2011 13:31:39 +0000 (GMT) Received: from HDXDSP11.us.lmco.com ([fe80::c04a:c222:3486:3e3]) by HDXHTPN7.us.lmco.com ([fe80::f1:ff4b:90a4:695%14]) with mapi id 14.01.0355.002; Wed, 07 Dec 2011 06:31:39 -0700 Date: Wed, 07 Dec 2011 13:31:38 +0000 From: "Fitch, Scott C" In-reply-to: <000101ccb48b$06819070$1384b150$@nwlink.com> X-Originating-IP: [158.188.95.10] To: Jim Schaad , "plasma@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Thread-Topic: EXTERNAL: RE: [plasma] S/MIME Capabilities Thread-Index: AcyTR93+zP+wCizmT46LHSpiVqxaJghfbe0AAAe1A/A= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <000101ccb48b$06819070$1384b150$@nwlink.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110, 1.0.211, 0.0.0000 definitions=2011-12-07_05:2011-12-07, 2011-12-07, 1970-01-01 signatures=0 Subject: Re: [plasma] EXTERNAL: RE: S/MIME Capabilities X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 13:31:49 -0000 Exactly. That will help us operate in the hybrid (No S/MIME, PKI S/MIME, Plasma) world we're destined to be in for a long time. Scott Fitch Cyber Architect scott.c.fitch@lmco.com -----Original Message----- From: Jim Schaad [mailto:jimsch@nwlink.com] Sent: Tuesday, December 06, 2011 9:50 PM To: Fitch, Scott C; plasma@ietf.org Subject: EXTERNAL: RE: [plasma] S/MIME Capabilities Just to be clear, you are suggesting that an attribute defined by which a sender says "I understand Plasma" just like there is one which says I understand inner binary. Recipients could then store this attribute as part of the senders capabilities. This is totally trivial and yes we should do it. I assume that this would just be a "binary" value - I do or do not support it. If a new version of Plasma ever comes into existence then a new attribute with a different OID value would be created. There is no need to talk about algorithms or advance vs basic here. Jim > -----Original Message----- > From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On > Behalf Of Fitch, Scott C > Sent: Tuesday, October 25, 2011 12:00 PM > To: plasma@ietf.org > Subject: [plasma] S/MIME Capabilities > > Section 5.2.1 notes the backwards compatibility requirement with > existing S/MIME where a sender can create recipient info structures > for recipients it > can discover keys for. > > Should there be an equivalent mechanism to indicate a sender's support > for plasma, similar to the way that S/MIME indicates current capabilities? This > could be helpful, particularly when sending messages with Advanced Policies. > > -Scott > _______________________________________________ > plasma mailing list > plasma@ietf.org > https://www.ietf.org/mailman/listinfo/plasma From jimsch@nwlink.com Thu Dec 8 14:07:59 2011 Return-Path: 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 ; 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 ; 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 ; 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 ; Thu, 8 Dec 2011 14:07:57 -0800 (PST) From: "Jim Schaad" To: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From trevorf@exchange.microsoft.com Mon Dec 12 15:13:46 2011 Return-Path: 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 6E2D221F84FB for ; Mon, 12 Dec 2011 15:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 3bLfB8A3DHDh for ; Mon, 12 Dec 2011 15:13:43 -0800 (PST) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by ietfa.amsl.com (Postfix) with ESMTP id DE2A221F84E5 for ; Mon, 12 Dec 2011 15:13:42 -0800 (PST) Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.3.5.0; Mon, 12 Dec 2011 15:13:42 -0800 Received: from PIO-MLT-05.exchange.corp.microsoft.com (157.54.94.22) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.3.5.1; Mon, 12 Dec 2011 15:13:42 -0800 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by PIO-MLT-05.exchange.corp.microsoft.com ([fe80::d940:e316:1daa:5e6a%10]) with mapi id 14.03.0005.000; Mon, 12 Dec 2011 15:13:41 -0800 From: Trevor Freeman To: Jim Schaad , "plasma@ietf.org" Thread-Topic: [plasma] Where is the PEP? Thread-Index: Acy18pICuzH8Oic9Q1CxM894eCe30wDLOwlg Date: Mon, 12 Dec 2011 23:13:41 +0000 Message-ID: References: <004401ccb5f5$c679d570$536d8050$@nwlink.com> In-Reply-To: <004401ccb5f5$c679d570$536d8050$@nwlink.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.104] Content-Type: multipart/alternative; boundary="_000_E545B914D50B2A4B994F198378B1525D42882443DFM1412exchange_" MIME-Version: 1.0 Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 23:13:46 -0000 --_000_E545B914D50B2A4B994F198378B1525D42882443DFM1412exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, Here is my take. There does not seem consensus over the exact role of a PEP, and maybe that = is by design. If you look at XACML v3 core it cites rfc3189 as a normative reference. Bot= h XACML and 3198 define the PEP role yet the definitions are not completely= aligned. 3198 defies a PEP as:- Policy enforcement: The execution of a policy decision. Policy Enforcement Point (PEP): A logical entity that enforces policy decis= ions (See also "policy enforcement") You can merge the two statements to be more concise i.e. A PEP is a logical= entity responsible for the execution of policy decisions. This s a fairly = general purpose, any policy model. XACML is more restrictive. It defines PEP as:- The system entity that performs access control by making decision requests = and enforcing authorization decisions. This is very much an access control policy model definition. It also implie= s a trust model. The policy decision requested by both the Plasma and XACML PEP is "can the = client\user access the specified message/data". In order to execute the permitted decision in a Plasma PEP, we need both th= e encrypted data and the decryption key. This is distinct from an XACML PEP= which has access to the clear text data and can simply relase the data. Th= e critical difference between the two is the trust model. In Plasma we do n= ot unconditionally trust the PEP with the clear txt data; plasma performs a= n access check first, and then releases the clear text data to the PEP. XAC= ML trusts the PEP with all clear text data regardless of any access check. The decision request is the same for both PEPs, but the execution of the de= cision is different because of the different trust models. Trevor -----Original Message----- From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of= Jim Schaad Sent: Thursday, December 08, 2011 2:07 PM To: plasma@ietf.org Subject: [plasma] Where is the PEP? At the last IETF meeting, Trevor and I got together to try and hammer out t= he 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 attrib= ute". 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 pl= ace 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 fr= om the PEP to the PDP. I found the follow document "SAML 2.0 Profile of XA= CML, 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 statem= ent onto a XACML request. The expectation is that this would be done by th= e PEP (or some entity between the PEP and the PDP) that is highly trusted a= s 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 an= d got me thinking about the question of where the PEP and PDP boundaries re= ally 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 a= re two different things that access is being granted to and this is not exp= licitly spelled out in the model. Access is being granted to the E-Mail message: This is where we are thinkin= g 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 liv= ing. In this case the PEP is not a fully trusted entity and does not actua= lly 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 t= he 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 the= refore what things can be done. The issue in this case is what level of tr= ust 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 cas= e 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 SAM= L Assertion in an XACML Attribute and leave the PDP to re-distribute it aro= und. Comments? Jim _______________________________________________ plasma mailing list plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma --_000_E545B914D50B2A4B994F198378B1525D42882443DFM1412exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 

Here is my take.

 

There does not seem consensus over the exact role= of a PEP, and maybe that is by design.

 

If you look at XACML v3 core it cites rfc3189 as = a normative reference. Both XACML and 3198 define the PEP role yet the defi= nitions are not completely aligned. 3198 defies a PEP as:-

 

Policy en= forcement:  The execution of a policy dec= ision.

Policy En= forcement Point (PEP): A logical entity that enforces policy decisions (See= also "policy enforcement")

 

You can merge the two statements to be more conci= se i.e. A PEP is a logical entity responsible for the execution of policy d= ecisions. This s a fairly general purpose, any policy model.

 

XACML is more restrictive. It defines PEP as:-

 

The system entity that performs access control by making decis= ion requests and enforcing authorization decisions.

 

This is very much an access control policy model = definition. It also implies a trust model.

 

 

The policy decision requested by both the Plasma = and XACML PEP is “can the client\user access the specified message/da= ta”.

 

In order to execute the permitted decision in a P= lasma PEP, we need both the encrypted data and the decryption key. This is = distinct from an XACML PEP which has access to the clear text data and can = simply relase the data. The critical difference betwe= en the two is the trust model. In Plasma we do not unconditionally trust th= e PEP with the clear txt data; plasma performs an access check first, and t= hen releases the clear text data to the PEP. XACML trusts the PEP with all clear text data regardless of any a= ccess check.

 

The decision request is the same for both PEPs, b= ut the execution of the decision is different because of the different trus= t models.

 

Trevor

 

 

-----Original Message-----
From: plasma-bounces@ietf.org [mailto:plasma-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Thursday, December 08, 2011 2:07 PM
To: plasma@ietf.org
Subject: [plasma] Where is the PEP?

 

At the last IETF meeting, Trevor and I got togeth= er 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 wo= rk did not appear to have a good way of returning error information for suc= h items as "missing attribute".&= nbsp; 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 pl= ace to base some of the work from.

 

In the process of doing this, one of the things t= hat 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&qu= ot;

http://docs.oasis-open.org/xacml/3.0/= xacml-profile-saml2.0-v2-spec-cs-01-en.

pdf which game a "simple" method of map= ping the attributes of a SAML statement onto a XACML request.  The expectation is that this would be done by the PEP (or some entit= y between the PEP and the PDP) that is highly trusted as it does the mappin= g 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 s= hould 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 mo= del.

 

Access is being granted to the E-Mail message: Th= is 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 actu= ally 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 reso= urce 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 en= tity we are calling the PEP (none) and therefore what level of validation o= f 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

 

 

_______________________________________________

plasma mailing list

plasma@ietf.org=

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

--_000_E545B914D50B2A4B994F198378B1525D42882443DFM1412exchange_--