[plasma] Plasma Policy discovery via ABFAB

Trevor Freeman <trevorf@exchange.microsoft.com> Thu, 31 March 2011 09:03 UTC

Return-Path: <trevorf@exchange.microsoft.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 1051E3A680E for <plasma@core3.amsl.com>; Thu, 31 Mar 2011 02:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.998
X-Spam-Level:
X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 VbtEBEOcDcZB for <plasma@core3.amsl.com>; Thu, 31 Mar 2011 02:02:55 -0700 (PDT)
Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by core3.amsl.com (Postfix) with ESMTP id 81BB128C188 for <plasma@ietf.org>; Thu, 31 Mar 2011 02:02:55 -0700 (PDT)
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.1.218.12; Thu, 31 Mar 2011 02:04:34 -0700
Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 31 Mar 2011 02:04:34 -0700
Received: from DF-M14-11.exchange.corp.microsoft.com ([fe80::cc46:3da5:bed6:8dfc]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi id 14.01.0218.012; Thu, 31 Mar 2011 02:04:33 -0700
From: Trevor Freeman <trevorf@exchange.microsoft.com>
To: "plasma@ietf.org" <plasma@ietf.org>
Thread-Topic: Plasma Policy discovery via ABFAB
Thread-Index: AcvvgmLzR5SqFqaqRjG7I7s9CsQbWg==
Date: Thu, 31 Mar 2011 09:04:32 +0000
Message-ID: <E545B914D50B2A4B994F198378B1525D2EF132DD@DF-M14-11.exchange.corp.microsoft.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.123.12]
Content-Type: multipart/mixed; boundary="_004_E545B914D50B2A4B994F198378B1525D2EF132DDDFM1411exchange_"
MIME-Version: 1.0
Subject: [plasma] Plasma Policy discovery via ABFAB
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: Thu, 31 Mar 2011 09:03:01 -0000

Since there was some interest in policy discovery at the BoF, I have tried to illustrate how this might happen in Plasma with an AbFab infrastructure.

Since the full authentication and exchange of claims process is relatively "expensive" we did not want this exchange to happen for every message. We are proposing a model similar to Kerberos where the full authentication process results in a relatively long lived token  issued by the PDP STS; this long lived token is then used for subsequent transactions with the PDP STS. The roll token in our proposed model is therefore equivalent to a Kerberos TGT.

The subject has one or more roles registered with the PDP STS. Each roll has a set of polices which the subject is allowed to assert in email. The roll token lists all the policies that the roll can assert in that roll. A roll may optionally be associated with an email address if the roll has a separate mailbox to the subjects personal mailbox. A subject can have associations with multiple PDP STS's. The set of PDP STS's is a matter of local policy for the Plasma client.

When bootstrapping a plasma client it would first have to discover all the roll tokens for all the PDP STS's it has in local policy. It starts by making a Get Tokens request to each PDP (line 1 in the slide) over HTTPS.

Then EAP would be initiated over the HTTPS tunnel where the subject would supply their realm name (line 2)

The PDP STS would then make a mutually authenticated radius\diameter connection to the realm IdP STS supplied by the subject (line 3)

The subject would then authenticate to the IdP STS via an EAP tunnel between subject and IdP STS (line 4). If we were using EAP Fast the client would build a TLS tunnel over the HTTPS session to the IdP STS.

The PDP STS then sends a list of claims required to the IdP STS(line 5).

The IdP STS then returns the SAML token with the requested claims to the PDP STS (line 6).

The PDP STS then returns one or more roll tokens to the subject (Line 7).

The Plasma client would now be bootstrapped ready to send protected email.

Dr Trevor Freeman  Senior Security Strategist
End to End Trust Team<http://www.microsoft.com/mscorp/twc/endtoendtrust/default.mspx>
Microsoft Trustworthy Computing <http://www.microsoft.com/mscorp/twc/default.mspx>