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

From: IETF Secretariat <[email-masked]>
Date: Thu, 3 Feb 2011 11:54:24 -0800 (PST)

A new IETF non-working group email list has been created.

List address: [email-masked]
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.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 4 Feb 2011 15:00:18 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Trevor Freeman
> Sent: Thursday, February 03, 2011 2:56 PM
> To: [email-masked]
> Cc: [email-masked]; 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
> 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:[email-masked]]
> Sent: Thursday, February 03, 2011 11:54 AM
> To: IETF Announcement list
> Cc: [email-masked]; [email-masked]; Trevor Freeman
> Subject: New Non-WG Mailing List: plasma -- The PoLicy Augmented S/Mime
> (plasma) bof discussion list
> 
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.
> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Josh Howlett <[email-masked]>
Date: Tue, 8 Feb 2011 10:27:20 +0000

Thank you. After a quick review of your docs, my sense is that Abfab could make sense in your scenarios.

If I have understood you correctly, I think you are suggesting refactoring Schaad-eps-trust such that it can use alternative bindings: WS-Trust or AAA.

I'm still undecided whether we are best served using a general purpose AAA-XML attribute, or domain-specific AAA-SAML and AAA-PLASMA attributes. They both share certain requirements of the AAA layer.

The consideration that weighs most in my mind is the implementation implications of a general purpose XML attributes. We definitely don't want to require AAA proxies to parse the attribute's XML blob to determine the next hop.

However, there's a similar issue in the AAA-SAML case where AAA proxies need to disambiguate between different types of SAML Issuers. I have suggested (see attached) using standard function-specific identifiers in the AAA Network Access Identifier. So, PLASMA could perhaps also define an identifier(s) that provide the necessary routing cue(s).

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

Subject: RE: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml
From: Josh Howlett <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Leif Johansson <[email-masked]>, "[email-masked]" <[email-masked]>, Josh Howlett <[email-masked]>
Date: Tue, 18 Jan 2011 16:08:56 +0000

>     >> Control question for Sam and Scott: is it possible (and
>     >> reasonably easy) to do SP-centric attribute aggregation for
>     >> abfab, by which I mean having the SP issue additional attribute
>     >> queries to IdPs within the AAA-centric trust model proposed by
>     >> Sam and Josh?
>
>     Josh> Yes, possible and easy (assuming, obviously, we can assume
>     Josh> that the SPs and IdP have a common identifier for the
>     Josh> subject).
>
> Josh, I suspect you are right, but the details are not clear to me.

Nor me in truth; I suspect that I am about to discover it was inadvisable of me to claim 'easy' :-)

> How does the SP address the request to a particular AA?

The model that I have in mind is that we specify a set of standard endpoint locator names for different type of Issuer roles. These can be used, in conjunction with the NAI realm of the Issuer, to construct a complete NAI.

e.g. say we specify the "saml-20-aa" name to mean a SAML 2.0 attribute authority. An SP wanting to route a message to this actor to example.com prefixes the realm of the intended Issuer with this, thus "saml-20-aa.example.com". The AAA SAML attribute within this request message contains a SAML Request message containing the identifier for the subject.

Josh.