Re: [plasma] Delegation scenario

"Skedd, Richard (UK)" <Richard.Skedd@baesystems.com> Tue, 06 December 2011 13:56 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 8110A21F8B3F for <plasma@ietfa.amsl.com>; 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 <plasma@ietfa.amsl.com>; 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 <plasma@ietf.org>; 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: <CB55784F96DEBE4B972015A2587A1DA002D2DA2B@GLKMS2105.GREENLNK.NET>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Delegation scenario
thread-index: AcyTPvJuZ6lTqdglQi+54J/v8g5UNQCWpMtQByQ9/MAAe836IA==
From: "Skedd, Richard (UK)" <Richard.Skedd@baesystems.com>
To: "Fitch, Scott C" <scott.c.fitch@lmco.com>, "Trevor Freeman" <trevorf@exchange.microsoft.com>, <plasma@ietf.org>
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." <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: Tue, 06 Dec 2011 13:56:08 -0000

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.
********************************************************************