Subject: [smime] FW: I-D Action:draft-freeman-message-access-control-req-00.txt

From: Trevor Freeman <[email-masked]>
Date: Fri, 21 Jan 2011 17:27:36 +0000

This should be of interest to members of the members of the list. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, January 20, 2011 3:15 PM
To: [email-masked]
Subject: I-D Action:draft-freeman-message-access-control-req-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Requirements for Message Access Control
	Author(s)       : T. Freeman, et al.
	Filename        : draft-freeman-message-access-control-req-00.txt
	Pages           : 17
	Date            : 2011-01-20

There are many situations where organizations want to include
  information which is subject to regulatory or other complex access
  control policy in email. Regulated information requires some form of
  robust access control to protect the confidentiality of the
  information. The Enhanced Security Services for S/MIME [rfc2634]
  defines an access control mechanism for S/MIME (eSSSecurityLabel).
  This is a signed attribute of a SignedData object which indicates the
  access control policy for the message. The fact that this is a signed
  attribute protects the integrity of the data and the binding of the
  label to the message but does not protect the confidentiality of the
  information i.e. at the point where you lean the access control policy
  to the data you also have access to the data. While the signature
  provides integrity for the label over the clear text, it is
  susceptible to unauthorized removal i.e. if you only have SignedData
  message, any MTA in the mail path can remove a signature layer and
  therefore remove the access control data.  Encrypting the signed
  message protects the confidentiality of the data and protects the
  SignedData from unauthorized removal but this hides the ESS security
  label.

  From a regulatory enforcement perspective this is an extremely weak
  form of access control because cryptographic access to the data is
  given before the access check. The correct enforcement of the access
  check totally depends on the configuration of the recipients email
  client. Since the cryptographic access is granted before the access
  checks, there is no significant impediment for a recipient who is
  unauthorized under the policy to access the data. A stronger
  enforcement model is needed for regulatory control for email where
  cryptographic access is only granted after the access check.

  There are also many users on the Internet today who have some form of
  authentication credential but they are not X.509 certificates and who
  therefore cannot use S/MIME. There are now available, standard based
  services (e.g. [SAML-overview]) which abstract the specifics of a
  technology used to authenticate uses from the application itself (S/MIME in this case). Adoption of this abstraction model would enable
  a broader set of users who have other types to authentication
  credentials to be able to use S/MIME to secure email. It also allows
  for new authentication technology to be deployed without impacting the
  core S/MIME protocol. 

  This document specifies the requirements for:-

Providing robust access control for S/MIME

An abstraction layer for supporting other types of credentials for

using S/MIME.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-freeman-message-access-control-req-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Jan 2011 09:37:46 -0800

> This should be of interest to members of the members of the list.

Should be, yes. Could you explain a bit of the motivation for the 
document? Is there a particular regulatory driver for this, or just a 
general desire to make this available? Knowing this would help people 
understand your design and possibly make comments on it.

---

From: Trevor Freeman <[email-masked]>
Date: Fri, 21 Jan 2011 18:26:06 +0000

Hi Paul,

First motivation is an observation that there a number of scenarios where the natural course of action would be to send some information in a message which is covered by one or more polices. We see that email is not being used in these casas or is being used with some risk of non-compliance because of the lack of policy enforcement. Those polices may be for example a regulatory policy, or an organization policy or both. The duty to enforce the policy is asymmetric by that I mean the onus is on the sender to ensure the information is only released when the other parties have passed the policy requirements. With ESS today the onus is on the recipient to not read the email. With content published on the web, the requestor has to convince the web site to release the information and we want to use the same model for email. I am working with a number of Aerospace and Defense companies which has as an industry adopted S/MIME for email. This is delivering well as far as the existing standard can but we have found it lacking when it comes to delivering regulatory compliance. I have discussed the same issues with representative from other verticals such as healthcare and they have agreed with the observations. 

Another motivation is the observation that we still have many situations where users don't have X.509 certificates and are hence prevented from participating in S/MIME.  With abstraction models such as SAML, it is now possible for the specifics of the authentication to be abstracted from an application. If we can deliver the same benefit to email as SAML has delivered to the web we can switch the requirement to users having a policy conformant credential and the relying part does not care what. It could be OTP or biometric or whatever as long as it's the required strength rather than it MUST be an X.509 certificate.

Overall we are looking to convergence of email and the web from a policy perspective. If you publish some content with the web or send it via email the same policies need apply. The same sets of attribute you use to access web for access control policy content should get you the same content via email. 

We think we can achieve the objectives and, within the scope of policy, and be backwards compatible with the existing standard. If the sender is convinced some set of recipients pass the policy check and they can find X.509 certificates, they can use the existing mechanism else you use the new mechanism. We believe we can mix both on the same message. 

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Friday, January 21, 2011 9:38 AM
To: [email-masked]
Subject: Re: [smime] FW: I-D Action:draft-freeman-message-access-control-req-00.txt

> This should be of interest to members of the members of the list.

Should be, yes. Could you explain a bit of the motivation for the document? Is there a particular regulatory driver for this, or just a general desire to make this available? Knowing this would help people understand your design and possibly make comments on it.
_______________________________________________
smime mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/smime

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 21 Jan 2011 10:54:39 -0800

I have additionally released two documents which provide a potential method
of implementing the requirements

These are:
      http://www.ietf.org/id/draft-schaad-eps-smime-00.txt  which describes
the additions to the CMS and S/MIME formats to support the concept and
     http://www.ietf.org/id/draft-schaad-eps-trust-00.txt which gives a
possible description of how to communicate between the mail client and the
enforcement server.

Jim

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Trevor Freeman
> Sent: Friday, January 21, 2011 9:28 AM
> To: Smime ([email-masked])
> Subject: [smime] FW: I-D Action:draft-freeman-message-access-control-req-
> 00.txt
> 
> From: [email-masked] [mailto:i-d-announce-
> [email-masked]] On Behalf Of [email-masked]
>   technology used to authenticate uses from the application itself (S/MIME
in
> this case). Adoption of this abstraction model would enable
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
Internet-
> Draft.