Re: [plasma] [abfab] FW: New Non-WG Mailing List: plasma -- The PoLicy Augmented S/Mime (plasma) bof discussion list

"Jim Schaad" <ietf@augustcellars.com> Fri, 04 February 2011 22:36 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: plasma@core3.amsl.com
Delivered-To: plasma@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045F63A69D4; Fri, 4 Feb 2011 14:36:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8Htq1IwplPu; Fri, 4 Feb 2011 14:36:55 -0800 (PST)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id EE8003A6998; Fri, 4 Feb 2011 14:36:54 -0800 (PST)
Received: from TITUS (static-66-14-119-7.bdsl.verizon.net [66.14.119.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTP id 57EE76EFB8; Fri, 4 Feb 2011 14:40:20 -0800 (PST)
From: "Jim Schaad" <ietf@augustcellars.com>
To: <abfab@ietf.org>, <plasma@ietf.org>
References: <20110203195424.DEC1A3A6ACC@core3.amsl.com> <E545B914D50B2A4B994F198378B1525D1AC80F92@DF-M14-12.exchange.corp.microsoft.com>
In-Reply-To: <E545B914D50B2A4B994F198378B1525D1AC80F92@DF-M14-12.exchange.corp.microsoft.com>
Date: Fri, 4 Feb 2011 15:00:18 -0800
Message-ID: <005701cbc4bf$4ba0fb30$e2e2f190$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFp21AcUcEMBZHlO9sjhNrVDy5kBgEZvIDHlKz2J5A=
Content-Language: en-us
X-Mailman-Approved-At: Fri, 04 Feb 2011 14:48:09 -0800
Subject: Re: [plasma] [abfab] FW: New Non-WG Mailing List: plasma -- The PoLicy Augmented S/Mime (plasma) bof discussion list
X-BeenThere: plasma@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." <plasma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 04 Feb 2011 22:36:56 -0000

I would like to add a few additional things to this as well.

We are currently looking at a proposal that is based on WS-Trust (SOAP based
token system) for communications between the mail client and the mail policy
server and, while using SAML, are placing how the SAML assertion(s) are
obtained is out of scope.   However I think that a good alternative to this
might be to look at using the ABFAB architecture.  We would then have the
mail client talking some protocol to the mail policy server which would be
using the ABFAB architecture to talk AAA to the correct identity service.
In some cases the identity service and the mail policy server would be
co-located, but this would be invisible to the mail client.

Doing this would simplify things as the correct SAML assertion would be
obtained by the policy server and it can ask for the type of details that it
wants without the client having to try and guess what is required.  On the
other hand it might complicate issues as we are looking at the ability for
the mail policy service to issue "short-term" tokens to the mail client
after having gone through a full policy check that stands in for abilities.
Thus not all of the ABFAB EAP would be used all of the time.

If you have an interest in talking about this, it would be better to join
the PLASMA mailing list and respond there.

Jim


> -----Original Message-----
> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of
> Trevor Freeman
> Sent: Thursday, February 03, 2011 2:56 PM
> To: abfab@ietf.org
> Cc: jimsch@nwlink.com; Trevor Freeman
> Subject: [abfab] FW: New Non-WG Mailing List: plasma -- The PoLicy
> Augmented S/Mime (plasma) bof discussion list
> 
> PLASMA - Policy Augmented S/Mime
> 
> Description: Current S/MIME mechanisms provide cryptographic access to the
> message based on the identity of the recipient at the time of
transmission. Any
> additional access control enforcement depends on the configuration of the
> recipients email client. Several Internet-Drafts have been submitted that
> establish a more robust access control mechanism where cryptographic
access
> to the message is only granted after the access check.
> 
> This proposed working group would develop a framework for enforcing a more
> robust access control mechanism, based on existing CMS, S/MIME and SAML-
> based policy enforcement standards. The working group will also develop
any
> necessary extensions to these base protocols specific to this problem
space.
> 
> Given the mutual interest in SAML - this work may be of interest to some
of
> you.
> 
> -----Original Message-----
> From: IETF Secretariat [mailto:ietf-secretariat@ietf.org]
> Sent: Thursday, February 03, 2011 11:54 AM
> To: IETF Announcement list
> Cc: plasma@ietf.org; jimsch@nwlink.com; Trevor Freeman
> Subject: New Non-WG Mailing List: plasma -- The PoLicy Augmented S/Mime
> (plasma) bof discussion list
> 
> A new IETF non-working group email list has been created.
> 
> List address: plasma@ietf.org
> Archive: http://www.ietf.org/mail-archive/web/plasma/
> To subscribe: https://www.ietf.org/mailman/listinfo/plasma
> 
> Description:
> Current S/MIME mechanisms provide cryptographic access to the message
> based on the identity of the recipient at the time of transmission. Any
> additional access control enforcement depends on the configuration of the
> recipients email client. Several Internet-Drafts have been submitted that
> establish a more robust access control mechanism where cryptographic
access
> to the message is only granted after the access check. This list is
devoted to the
> discussion of these drafts and any related future submissions.
> 
> For additional information, please contact the list administrators.
> _______________________________________________
> abfab mailing list
> abfab@ietf.org
> https://www.ietf.org/mailman/listinfo/abfab