< draft-freeman-plasma-requirements-02.txt   draft-freeman-plasma-requirements-03.txt >
Network Working Group T. Freeman Network Working Group T. Freeman
Internet-Draft Microsoft Corp. Internet-Draft Microsoft Corp.
Intended status: Informational J. Schaad Intended status: Informational J. Schaad
Expires: January 7, 2013 Soaring Hawk Consulting Expires: February 24, 2013 Soaring Hawk Consulting
P. Patterson P. Patterson
Carillon Information Security Inc Carillon Information Security Inc
July 6, 2012 August 23, 2012
Requirements for Message Access Control Requirements for Message Access Control
draft-freeman-plasma-requirements-02 draft-freeman-plasma-requirements-03
Abstract Abstract
There are many situations where organizations want to protect There are many situations where organizations want to protect
information with robust access control, either for implementation of information with robust access control, either for implementation of
intellectual property right protections, enforcement of contractual intellectual property right protections, enforcement of contractual
confidentiality agreements or because of legal regulations. The confidentiality agreements or because of legal regulations. The
Enhanced Security Services (ESS) for S/MIME defines an access control Enhanced Security Services (ESS) for S/MIME defines an access control
mechanism which is enforced by the recipient's client after mechanism which is enforced by the recipient's client after
decryption of the message. The ESS mechanism therefore is dependent decryption of the message. The ESS mechanism therefore is dependent
skipping to change at page 3, line 7 skipping to change at page 3, line 7
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Data Access Control . . . . . . . . . . . . . . . . . . . 4 1.1 Data Access Control . . . . . . . . . . . . . . . . . . . . 4
1.2. Encrypted E-Mail Using Web-based Credentials . . . . . . . 5 1.2 Encrypted E-Mail Using Web-based Credentials . . . . . . . 5
1.3. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. ESS Security Labels . . . . . . . . . . . . . . . . . . . 8 2.1. ESS Security Labels . . . . . . . . . . . . . . . . . . . 11
2.2. Access Control and the Web . . . . . . . . . . . . . . . . 10 2.2. Access Control and the Web . . . . . . . . . . . . . . . . 13
2.3. Information Asset Protection . . . . . . . . . . . . . . . 12 2.3. Information Asset Protection . . . . . . . . . . . . . . . 15
2.4. Authentication Assurance Frameworks . . . . . . . . . . . 13 2.4. Authentication Assurance Frameworks . . . . . . . . . . . 16
3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . . 14 2.5 Electronic Signatures: Authentication vs. Authorization . . 16
3.1 Consumer to Consumer Secure Email . . . . . . . . . . . . . 14 3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Business to Consumer Secure Email . . . . . . . . . . . . 15 3.1 Consumer to Consumer Secure Email . . . . . . . . . . . . . 18
3.3 Business to Business Ad-Hoc Email . . . . . . . . . . . . . 18 3.2. Business to Consumer Secure Email . . . . . . . . . . . . 18
3.4 Business to Business Regulated Email . . . . . . . . . . . 19 3.3 Business to Business Ad-Hoc Email . . . . . . . . . . . . . 21
3.5 Delegation of Access to Email . . . . . . . . . . . . . . . 23 3.4 Business to Business Regulated Email . . . . . . . . . . . 23
3.6 Regulated Industry Email . . . . . . . . . . . . . . . . . . 23 3.5 Delegation of Access to Email . . . . . . . . . . . . . . . 27
3.7 Regulated Email Compliance Verification . . . . . . . . . . 25 3.6 Regulated Industry Email . . . . . . . . . . . . . . . . . . 28
3.8 Email Pipeline Inspection . . . . . . . . . . . . . . . . . 25 3.7 Regulated Email Compliance Verification . . . . . . . . . . 29
3.9 Scalable Decision Making . . . . . . . . . . . . . . . . . . 26 3.8 Email Pipeline Inspection . . . . . . . . . . . . . . . . . 29
3.10 Related scenarios . . . . . . . . . . . . . . . . . . . . 26 3.9 Distribution List Expansion . . . . . . . . . . . . . . . . 30
4. Plasma Data Centric Security Model . . . . . . . . . . . . . . 30 3.10 Scalable Decision Making . . . . . . . . . . . . . . . . . 31
4.1 Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.11 Related scenarios . . . . . . . . . . . . . . . . . . . . 32
4.2 Policy Data Binding . . . . . . . . . . . . . . . . . . . . 39 4. Plasma Data Centric Security Model . . . . . . . . . . . . . . 36
4.3 Content Creation Workflow . . . . . . . . . . . . . . . . . 40 4.1 Plasma Client Server Key Exchange Level of Assurance . . . . 43
4.4 Content Consumption Workflow . . . . . . . . . . . . . . . . 41 4.2 Policy Data Binding . . . . . . . . . . . . . . . . . . . . 43
4.5 Internet Facing Plasma Servers . . . . . . . . . . . . . . . 42 4.3 Content Creation Workflow . . . . . . . . . . . . . . . . . 45
4.6 Policy Types . . . . . . . . . . . . . . . . . . . . . . . . 43 4.4 Content Consumption Workflow . . . . . . . . . . . . . . . . 46
5. Message Protection Requirements . . . . . . . . . . . . . . . 44 4.5 Plasma Proxy Servers . . . . . . . . . . . . . . . . . . . . 46
5.1. General Requirements . . . . . . . . . . . . . . . . . . . 44 4.6 Policy Types . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2. Basic Policy Requirements . . . . . . . . . . . . . . . . 46 5. Message Protection Requirements . . . . . . . . . . . . . . . 49
5.3. Advanced Policy Requirements . . . . . . . . . . . . . . . 46 5.1. General Requirements . . . . . . . . . . . . . . . . . . . 49
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 5.2. Basic Policy Requirements . . . . . . . . . . . . . . . . 51
7. Security Considerations . . . . . . . . . . . . . . . . . . . 49 5.3. Advanced Policy Requirements . . . . . . . . . . . . . . . 52
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 50 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
Appendix A. References . . . . . . . . . . . . . . . . . . . . . 51 7. Security Considerations . . . . . . . . . . . . . . . . . . . 55
A.1. Normative References . . . . . . . . . . . . . . . . . . . 51 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 56
A.2. Informative References . . . . . . . . . . . . . . . . . . 51 Appendix A. References . . . . . . . . . . . . . . . . . . . . . 57
Appendix B Authors' Addresses . . . . . . . . . . . . . . . . . . 52 A.1. Normative References . . . . . . . . . . . . . . . . . . . 57
Appendix C Document Change History . . . . . . . . . . . . . . . . 53 A.2. Informative References . . . . . . . . . . . . . . . . . . 57
Appendix B Authors' Addresses . . . . . . . . . . . . . . . . . . 58
Appendix C Document Change History . . . . . . . . . . . . . . . . 59
1. Introduction 1 Introduction
The S/MIME (Secure/Multipurpose Internet Mail Extensions) standard The S/MIME (Secure/Multipurpose Internet Mail Extensions) standard
[RFC5652] today provides digital signatures (for message integrity [RFC5652] today provides digital signatures (for message integrity
and data origination) and encryption (for data confidentiality). The and data origination) and encryption (for data confidentiality). The
Enhanced Security Services (ESS) for S/MIME [RFC2634] provides for Enhanced Security Services (ESS) for S/MIME [RFC2634] provides for
additional services including security labels (eSSSecurityLabel) additional services including security labels (eSSSecurityLabel)
which represent the access control policy. The label is a signed which represent the access control policy. The label is a signed
attribute in the signed data block of a message. The recipient of attribute in the signed data block of a message. The recipient of
the message is then responsible for checking that the recipient has a the message is then responsible for checking that the recipient has a
legitimate right to see the message based on the label. This type of legitimate right to see the message based on the label. This type of
skipping to change at page 4, line 30 skipping to change at page 4, line 30
The Cryptographic Message Syntax (CMS) [RFC5652] allows for a variety The Cryptographic Message Syntax (CMS) [RFC5652] allows for a variety
of different types of lock boxes to be applied to an encrypted of different types of lock boxes to be applied to an encrypted
message. This allows for a variety of different type of security message. This allows for a variety of different type of security
mechanisms to be used by the sender, and the recipient to process the mechanisms to be used by the sender, and the recipient to process the
message. However the S/MIME standard is currently solely based on message. However the S/MIME standard is currently solely based on
X.509 certificates. This means anyone without an X.509 certificate is X.509 certificates. This means anyone without an X.509 certificate is
unable to leverage the S/MIME protocol for securing Email. The vast unable to leverage the S/MIME protocol for securing Email. The vast
majority of users on the Internet have other forms of credentials majority of users on the Internet have other forms of credentials
(passwords, one time passwords, GPG/PGP keys etc.). (passwords, one time passwords, GPG/PGP keys etc.).
1.1. Data Access Control 1.1 Data Access Control
There are many situations where organizations want to include There are many situations where organizations want to include
information which is subject to regulatory or other complex access information which is subject to regulatory or other complex access
control policy in Email. Regulated information requires some form of control policy in Email. Regulated information requires some form of
robust access control to protect the confidentiality of the robust access control to protect the confidentiality of the
information. While ESS for S/MIME [RFC2634] defines an access information. While ESS for S/MIME [RFC2634] defines an access
control mechanism for S/MIME (eSSSecurityLabel), it is an extremely control mechanism for S/MIME (eSSSecurityLabel), it is an extremely
weak form of access control as the recipient is responsible for the weak form of access control as the recipient is responsible for the
enforcement and is given access to the data even if they fail to meet enforcement and is given access to the data even if they fail to meet
the criteria of the label. the criteria of the label.
skipping to change at page 5, line 39 skipping to change at page 5, line 39
form of access control because cryptographic access to the data is form of access control because cryptographic access to the data is
given before the access check. The correct enforcement of the access given before the access check. The correct enforcement of the access
check is dependent on the configuration of every recipient's Email check is dependent on the configuration of every recipient's Email
client. Since the cryptographic access is granted before the access client. Since the cryptographic access is granted before the access
checks, there is no cryptographic impediment for a recipient who is checks, there is no cryptographic impediment for a recipient who is
unauthorized under the policy to access the data. A stronger unauthorized under the policy to access the data. A stronger
enforcement model is needed for regulatory control for Email where enforcement model is needed for regulatory control for Email where
cryptographic access is only granted after the access check is cryptographic access is only granted after the access check is
successful. successful.
1.2. Encrypted E-Mail Using Web-based Credentials 1.2 Encrypted E-Mail Using Web-based Credentials
There are many users on the Internet today who have some form of There are many users on the Internet today who have forms of
authentication credential but the credentials are not X.509 authentication credential other than X.509 certificates. S/MIME today
certificates and who therefore cannot use S/MIME. Standard based can only use X.509 certificates to protect the confidentiality of a
services (e.g. [SAML-overview])are now available which abstract the message or the data origination authentication of the messages. This
specifics of an authentication technology used used to identify a means users without X.509 certificates cannot use S/MIME. Standard
subject from the application itself (S/MIME in this case). Adoption based services (e.g. [SAML-overview])are now available which
of this abstraction model would enable a broader set of abstract the specifics of an authentication technology used used to
authentication technologies to be able to use S/MIME to secure Email. identify a subject from the application itself (S/MIME in this case).
It also allows for new authentication technology to be deployed Adoption of this abstraction model would enable a broader set of
without impacting the core S/MIME protocol at the expense of adding a authentication technologies to be able to use S/MIME to secure Email
third party to the transaction. or confidentiality or data origination authentication. It also
allows for new authentication technology to be deployed without
impacting the core S/MIME protocol.
1.3. Vocabulary 1.3 Vocabulary
Mail User Agent (MUA) is a program or service used to manage a Some of these terms are the same as used by RFC3198. While the Plasma
user's email. The MUA may be a program run on the users computer actors are fundamentally the same as rfc3198, there are some minor
or a Web service accessed via the users browser. differences in the responsibilities of each actor with models such as
XACML.
Mail Transfer Agent (MTA) is a program that transfers email from Attribute Based Where the policy is specified by the set
one computer to another. An MTA implements both the sending and Access Control (ABAC) of attributes, their values and and any
receiving of email. relationship between attributes required to
authorize an action on a resource. These
attributes may be provided by the subject as
part of the decision request (Front End
Attribute Exchange) or discovered by the policy
decision service itself (Back End Attribute
Exchange). The policy for example may require
attributes about the subject, their device or
environment, a resource or the intended use of
the information.
A Cryptographic Lock Box is a per recipient data structure which Back End Attribute When subject attributes are directly sent
holds a content encryption key encrypted for a specific user. Exchange (BEE) from the attribute issuer to the PDEP.
CMS implements lock boxes as RecipientInfo structures.
Early Binding is the concept of creating the cryptographic lock Cipher text Plain text which has been processed by an
box for a recipient at the time the message is sent. (See to encryption algorithm to render it unreadable by
Late Binding). a program of human without the appropriate
cryptographic key.
Confidential A message has been protected to a known level
of confidence so that the contents are not
decipherable by unauthorized users.
Late Binding is the concept of creating the cryptographic lock box Content Encryption Key A key used to encrypt protected end user data.
for a recipient when the recipient attempts to decrypt the (See Key Encryption Key)
message. Late binding has a potential downside because the
sender cannot know what symmetric algorithms the recipient
supports which can lead to interoperability issues. (See Early
Binding)
Content Encryption Key (CEK) is a key used to encrypt protected end Cryptographic Lock Box A per recipient data structure which holds a
user data. (See Key Encryption Key) content encryption key encrypted for a specific
user. CMS implements lock boxes as
RecipientInfo structures.
Key Encryption Key (KEK) is a key used to encrypt a cryptographic Data Origination Enables the recipient to verify that data or
key, often a CEK. (See Content Encryption Key) Authentication messages have not been tampered with in transit
and that the originator is the expected sender.
Authentication denotes:- Decision Requester (DR) The service responsible for making policy
decision requests to the PDEP. In this model
the policy decision is enforced by the PDEP by
its control of cryptographic keys. The DR
enforces any obligations the PDEP may require
such as signing or encryption of the data,
generating audit events etc. An DR is distinct
from a Policy Enforcement Point in other models
such as XACML in that an DR is not by default
trusted with the clear text data. Policy
enforcement is preformed by the PDEP. An DR may
establish trust by presentation of attributes
about itself and its environment to show it is
trustworthy.
The sender is able to establish to a known level of confidence Early Binding The concept of creating the cryptographic lock
the identity of the recipient or box for a recipient at the time the message is
The recipient is able to establish to a known level of sent. (See to Late Binding).
confidence the identity of the sender.
Confidential denotes that a message has been protected to a known Front End Attribute When subject attributes are relayed from the
level of confidence so that the contents are not decipherable by Exchange (FEE) attribute issuer to the PDEP party by the
unauthorized users. plasma client.
Integrity Protected denotes that a recipient of a message can Integrity Protected A recipient of a message can determine to a
determine to a known level of confidence that a message has not known level of confidence that a message has
been modified between the time that it was created and it was not been modified between the time that it was
received by the recipient. created and it was received by the recipient.
Front End Attribute Exchange is when subject attributes are relayed Key Encryption Key A key used to encrypt a cryptographic key,
from the issuer to the relying party by the subject (KEK) often a CEK. (See Content Encryption Key)
Back End Attribute Exchange is when subject attributes are directly Late Binding The concept of creating the cryptographic lock
sent from the issuer to the relying party box for a recipient when the recipient attempts
to decrypt the message. Late binding has a
potential downside because the sender cannot
know what symmetric algorithms the recipient
supports which can lead to interoperability
issues. (See Early Binding)
Role Based Access Control (RBAC) is access control based on the Mail Transfer Agent A program that transfers email from one
assignment of authorizations to abstract job function or (MTA) computer to another. An MTA implements both the
principle known as a role. Subjects are then allowed to assume sending and receiving of email.
one or more roles based on their job needs. A role is distinct
from a group because a group is a collection of subjects which
has no intrinsic authorizations.
Attribute Based Access Control (ABAC) is where the policy is Mail User Agent A program or service used to manage a user's
specified by the set of attributes, their values and and any (MUA) email. The MUA may be a program run on the
relationship between attributes required to authorize an action users computer or a Web service accessed via
on a resource. These attributes may be provided by the subject the users browser.
as part of the decision request (Front End Attribute Exchange)
or discovered by the policy decision service itself (Back End
Attribute Exchange). The policy for example may require
attributes about the subject, their device or environment or
their intended use of the information.
1.4. Keywords Orthonym The correct name of a place or person or thing
Plain text The information in a state which can be
directly read by a human or an appropriate
application.
Policy (1) A human readable statement which defines a
course of action by an individual or
organization. These human readable statements
may be in the form of legislation, regulation,
a legal contract or organization goals.
(2) Technical controls for implementation of
the human readable policies. Policies may
stipulate many forms of technical controls
requirements such as data protection, access
control, data integrity, data origination, data
retention, etc.
Policy Administration The system entity that creates, maintains and
Point (PAP) publishes policies or policy collections. The
policies define the rules, their conditions and
actions associated with the policy.
Policy Collection A collection of one or more policies which is
associated with a role.. The policy collection
may also defines the logical relationship
between the policies.
Policy Decision and The system entity that evaluates the policy
Enforcement Point (PDEP)criteria published by a PAP, using attributes
supplied by a PIP to render decisions from
request made by DRs.
Policy Identifier The tag that is used to identify a policy. For
the purposes of our document we are focusing on
two different types of policy identifiers.
Object Identifiers (OIDs) are what are
currently used in many security policy systems
and are the only method of policy
identification supported by ESS security
labels. Additionally we will support URIs as
policy identifiers as they provide a more user
friendly method of uniquely identify a policy
and allow discovery of the policy.
Policy Information A service with issues assertions about subjects
Point (PIP) or the subject's environment e.g. a SAML
Security Token Service. This model supports
both front end and back end exchange of
assertions between the PIP and the PDEP.
Attributes can be distributed directly between
the PIP and the PDEP (Backbend Attribute
Exchange;BAE). Alternatively attributes may be
distributed via the DR (Front End Attribute
Exchange; FAE) There are two types of PIP based
on the types of attribute the PIP would assert
about the subject. A Identity Provider (IdP)
PIP will issue authentication attributes e.g.
information about how and when the subject
authenticated to the IdP. An IdP may also issue
attributes about the subject themselves e.g.
their full name, age or citizenship. An
attribute provider (AtP)PIP only issues
attributes about the subject or the subject's
environment.
Policy Label The data structure which holds one or more
policy identifiers and their logical
relationship.
Pseudonym A name that a person or group assumes for a
particular purpose, which differs from their
original or true name
Role An abstract principal which has a series of
authorizations assigned to it. Users as
assigned to roles to perform the duties of the
role. Users typically select a role to perform
a function to disambiguate which role they are
currently functioning as. A role is distinct
from a group because a group is a collection of
subjects which has no intrinsic authorizations.
Role Based Access Access control based on the assignment of
Control (RBAC) a role. Subjects are then allowed to assume
one or more roles based on their job needs.
We additional make use of the following terms:
Attribute The act of a client requesting and obtaining a
Request/Issuance set of attributes for a subject. The issuance
of attributes will itself be controlled by
policy and thus recursively embeds this same
picture in that process. For simplicity we use
SAML as the format for both requesting and
receiving attributes and would suggest the use
of the SAML 2.0 Assertion Query and Request
Protocol as one method for requesting the
necessary attributes. The attributes can be
requested either by the AR (front end attribute
exchange) or the PDEP (back end attribute
exchange).
Content Protection The protocol to be run by the DR to get the set
Request/Response of decisions and information required to
successfully create and encode a data block
with appropriate labeling. This protocol is
part of the work to be defined by this group.
Content Consumption The protocol to be run by the DR to obtain the
Request/Response permissions and information needed to decode
and access a data block with appropriate
labeling. This protocol is part of the work to
be defined by this group.
Content Distribution Can be any of a number of methods by which the
content is transmitted from the Content Creator
to the Content Consumer. These methods
include, but are limited to: Email, FTP, XMPP,
HTTP and SneakerNet.
1.4 Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
2. Background 2 Background
The S/MIME standard [RFC5751] provides a method to send and receive The S/MIME standard [RFC5751] provides a method to send and receive
secure MIME messages. While CMS allows for other types of security secure MIME messages. While CMS allows for other types of security
credentials to be used, S/MIME exclusively uses X.509 certificates credentials to be used, S/MIME exclusively uses X.509 certificates
[RFC5750] for the security credentials used for signing and [RFC5750] for the security credentials used for signing and
encryption operations. S/MIME uses an early binding mechanism for encryption operations. S/MIME uses an early binding mechanism for
encryption keys where the sender needs to discover the public key for encryption keys where the sender needs to discover the public key for
each recipient of an encrypted message before it can be sent. This each recipient of an encrypted message before it can be sent. This
requires the sender to maintain a cache of all potential recipient requires the sender to maintain a cache of all potential recipient
certificates (e.g. in a personal address book) and/or have the certificates (e.g. in a personal address book) and/or have the
skipping to change at page 13, line 13 skipping to change at page 16, line 13
recipient's mailbox. However it does not impose any finer grained recipient's mailbox. However it does not impose any finer grained
access control such as those required by many policies. S/MIME does access control such as those required by many policies. S/MIME does
define an extension mechanism for access control via an ESS security define an extension mechanism for access control via an ESS security
label [RFC2634] thou this mechanism has drawbacks (see above). label [RFC2634] thou this mechanism has drawbacks (see above).
2.4. Authentication Assurance Frameworks 2.4. Authentication Assurance Frameworks
A number of organizations have created taxonomies to define the A number of organizations have created taxonomies to define the
possible levels of identity assurance for electronic authentication. possible levels of identity assurance for electronic authentication.
The objective of the framework is to provide a simple abstraction the The objective of the framework is to provide a simple abstraction the
details of any specific combination of identity proofing, credential details of
technology, authentication technology from the authorization policy.
o Identity proofing and registration of subjects
o Tokens used by subjects for providing electronic identity
o The token management mechanisms
o Protocols used for subject to use tokens to authenticate to an
identity provider
o Protocols used by subjects to authenticate and pass attributes
to a relying party
These frameworks have been drafted by industry organizations [lib- These frameworks have been drafted by industry organizations [lib-
iaf][kan-iaf] and governments [SP800-63-1]. While all of these iaf][kan-iaf] and governments [SP800-63-1]. While all of these
frameworks may not agree on every aspect, at a macro level they do frameworks may not agree on every aspect, at a macro level they do
exhibit many similarities. A common theme in many is the adoption of exhibit many similarities. A common theme in many is the adoption of
a small number of levels of identity assurance, typically between 3- a small number of levels of identity assurance, typically between 3-
5. A simplified description of the levels is: 5. A simplified description of the levels is:
Level 1 Negligible confidence in the asserted identity Level 1 Negligible confidence in the asserted identity
Level 2 Some confidence in the asserted identity Level 2 Some confidence in the asserted identity
Level 3 Significant confidence in the asserted identity Level 3 Significant confidence in the asserted identity
Level 4 High confidence in the asserted identity Level 4 High confidence in the asserted identity
The framework defines broad characteristics in the area of identity The framework defines broad characteristics in the area of identity
proofing, credential type and management, identity provider proofing, credential type and management, identity provider
authentication and relying party authentication. authentication and relying party authentication.
2.5 Electronic Signatures: Authentication vs. Authorization
Electronic signatures on email are used today to show data
origination so only authentication is required. However with
transactions that are legally or regulatory significant,
authentication alone if frequently not enough. Policy requires other
factors to be considered to ensure the transaction meets policy
requirements.
The state of the system generating the signature
An indication of the signers intent
Attributes about the signer to indicate for example, job function
in the company, job assignments professional qualifications,
signing authority etc.
Many organizations would like email based work flows to be an option
for these transactions.
3. Use Case Scenarios 3. Use Case Scenarios
This section documents some use case scenarios the new protocol aims This section documents some use case scenarios the new protocol aims
to support. to support.
Author Note: Add legal document signing scenarios
3.1 Consumer to Consumer Secure Email 3.1 Consumer to Consumer Secure Email
One of the issues that is stopping the use of secure Email in One of the issues that is stopping the use of secure Email in
personal mail is the fact that consumers find certificates difficult personal mail is the fact that consumers find certificates difficult
to obtain and then use. One of the possible use cases of PLASMA is to to obtain and then use. One of the possible use cases of PLASMA is to
try and deal with this. The details of the use case are therefore: try and deal with this. The details of the use case are therefore:
Alice wants to send an Email message to Bob that is secure so that Alice wants to send an Email message to Bob that is secure so that
eavesdroppers cannot read it. Bob however has never obtained an X.509 eavesdroppers cannot read it. Bob however has never obtained an X.509
certificate for this purpose. Alice needs to ensure the following: certificate for this purpose. Alice needs to ensure the following:
skipping to change at page 15, line 22 skipping to change at page 19, line 20
In the first example, a bank (The Bank of Alice) has determined that In the first example, a bank (The Bank of Alice) has determined that
it will be using Email to distribute statements to its customers it will be using Email to distribute statements to its customers
(Bob). The information is confidential, so any channel of (Bob). The information is confidential, so any channel of
communication they selects must protect Bob's privacy. The bank communication they selects must protect Bob's privacy. The bank
needs to ensure the following: needs to ensure the following:
(a) Only Bob (or additional owners of the account) can read the (a) Only Bob (or additional owners of the account) can read the
Email Email
(b) Bob authenticates with a sufficient level of assurance. The same (b) Bob authenticates with a sufficient level of identity assurance.
authentication level used to do on-line banking would be The same identity assurance authentication level used to do on-
considered sufficient line banking would be considered sufficient
(c) Bob can verify the statement is from his bank (c) Bob can verify the statement is from his bank
(d) Bob can verify the statement has not been modified since his (d) Bob can verify the statement has not been modified since his
bank sent it. bank sent it.
The sequence of events would be as follows: The sequence of events would be as follows:
1. As part of routine end of the month processing, the Bank composes 1. As part of routine end of the month processing, the Bank composes
an Email to Bob. They includes the statement of balances and activity an Email to Bob. They includes the statement of balances and activity
skipping to change at page 16, line 47 skipping to change at page 20, line 46
but not to others. As an example, the mail message could contain a but not to others. As an example, the mail message could contain a
prescription, that specific portion of the message may need to be prescription, that specific portion of the message may need to be
read by Bob's pharmacist. Alice needs to ensure the following: read by Bob's pharmacist. Alice needs to ensure the following:
(a) Only authorized individuals can read the Email. However, the (a) Only authorized individuals can read the Email. However, the
definition of authorized will vary with the content of the definition of authorized will vary with the content of the
message and thus the policy applied. (General health issues will message and thus the policy applied. (General health issues will
certainly be treated differently than mental health issues, even certainly be treated differently than mental health issues, even
by a General Practitioner.) by a General Practitioner.)
(b) The message readers authenticate with a level 2 or above level (b) The Bob is required to authenticate with a identity assurance
of identity assurance. level 2 or above level.
(c) The Bob can verify the Email is from Alice. (c) The Bob can verify the Email is from Alice.
(d) The Bob can verify the Email has not been modified after Alice (d) The Bob can verify the Email has not been modified after Alice
sent it. sent it.
The sequence of events would be as follows: The sequence of events would be as follows:
1. Alice composes the Email to Bob. She includes some comments and 1. Alice composes the Email to Bob. She includes some comments and
suggestions for Bob and attaches the test results. suggestions for Bob and attaches the test results.
skipping to change at page 17, line 28 skipping to change at page 21, line 25
3. Alice's Email client knows the protections to apply to Doctor- 3. Alice's Email client knows the protections to apply to Doctor-
Patient communication; it knows to encrypt and integrity-protect Patient communication; it knows to encrypt and integrity-protect
the message. the message.
4. The protected Email is able to flow securely and seamlessly 4. The protected Email is able to flow securely and seamlessly
through existing Email infrastructure to Bob. The data is through existing Email infrastructure to Bob. The data is
protected while in transit or at rest. protected while in transit or at rest.
5. Bob receives the Email as sees it is a secure message from Alice. 5. Bob receives the Email as sees it is a secure message from Alice.
Bob can verify the message has not been altered. Bob Bob can verify the message has not been altered. Bob attempts to
attempts to opens the Email. Bob provides a Level 2 password to opens the Email. Bob provides a Level 2 password to retrieve
retrieve the necessary decryption keys. After Bob has the necessary decryption keys. After Bob has proved his
proved his identity, he is able to read the Email. identity, he is able to read the Email.
There are number of different places where the identity provider for There are number of different places where the identity provider for
Bob could live. The first is at Alice's office, Bob already has a Bob could live. The first is at Alice's office, Bob already has a
face-to-face relationship with Alice and the credential could be face-to-face relationship with Alice and the credential could be
setup in her office. A second could be Bob's insurance provider. setup in her office. A second could be Bob's insurance provider.
Bob has a relationship with his insurance provider as does Alice, Bob has a relationship with his insurance provider as does Alice,
thus it can serve as an trusted identity provider to healthcare thus it can serve as an trusted identity provider to healthcare
providers. A third location could be a federation of doctors in an providers. A third location could be a federation of doctors in an
area, potentially with other health providers (such as hospitals and area, potentially with other health providers (such as hospitals and
convalescent centers), Bob has setup an identity with Alice, but if convalescent centers), Bob has setup an identity with Alice, but if
skipping to change at page 18, line 6 skipping to change at page 21, line 52
types of situations could be dealt with by [I-D.ietf-abfab-arch]. types of situations could be dealt with by [I-D.ietf-abfab-arch].
There are a number of other additional services that could be There are a number of other additional services that could be
provided by the policy system. One example would be that if the provided by the policy system. One example would be that if the
information was time critical, if Bob does not access his message information was time critical, if Bob does not access his message
within a given time period, the policy server could notify Alice of within a given time period, the policy server could notify Alice of
this fact so that an alternate method of communication can be this fact so that an alternate method of communication can be
attempted with the same information. attempted with the same information.
3.3 Business to Business Ad-Hoc Email Author note: (add alternate 3.3 Business to Business Ad-Hoc Email Author note: (add alternate
recipient's as well) recipient's as well) i.e. add admin and forwarding for oof
Early in the relationship between two companies, it is frequently Early in the relationship between two companies, it is frequently
necessary to exchange sensitive information. This needs to occur necessary to exchange sensitive information. This needs to occur
before the relationship has matured to the point that a formal before the relationship has matured to the point that a formal
relationship is reflected through a legal agreement. Business owners relationship is reflected through a specific legal agreement.
need the agility to interact with potential partners without having Business owners need the agility to interact with potential partners
to engage their respective IT staffs as a prerequisite of the without having to engage their respective IT staffs as a prerequisite
communication. As example, the IT staff might need to provide cross of the communication. As example, the IT staff might need to provide
certifications and exposure of certificate repositories. cross certifications and exposure of certificate repositories.
As an example, Charlie works for Company Foo. He has just met Dave As an example, Charlie works for Company Foo. He has just met Dave
from Company Bar to discuss the prospect of a potential new business from Company Bar to discuss the prospect of a potential new business
opportunity. Following the meeting, Charlie wants to send Dave some opportunity. Following the meeting, Charlie wants to send Dave some
sensitive information relating to the new business opportunity. When sensitive information relating to the new business opportunity. When
Charlie sends the Email to Dave with the sensitive content, he must Charlie sends the Email to Dave with the sensitive content, he must
ensure the following objectives: ensure the following objectives:
(a) Only Dave can read the Email (a) Only Dave can read the Email
(b) Dave authenticates with a level 2 or above level of identity (b) Dave is required to authenticate with a identity assurance level
assurance 2 or above
(c) The Dave can verify the Email is from Charlie (c) The Dave can verify the Email is from Charlie
(d) The Dave can verify the Email has not been tampered with (d) The Dave can verify the Email has not been tampered with
(e) Charlie may also need to keep a record of the fact that Dave (e) Charlie may also need to keep a record of the fact that Dave
accessed the message and when it was done. accessed the message and when it was done.
The sequence of events Charlie would use is as follows: The sequence of events Charlie would use is as follows:
skipping to change at page 19, line 51 skipping to change at page 23, line 48
subcontractor to company Foo working on Program X. Company Foo sets subcontractor to company Foo working on Program X. Company Foo sets
up some business rules for access to program X data to ensure up some business rules for access to program X data to ensure
compliance with the export control licence requirements. Company compliance with the export control licence requirements. Company
Foo also set up separate rules to cover the confidentiality of its Foo also set up separate rules to cover the confidentiality of its
intellectual property contributed to Program X. Company Bar also sets intellectual property contributed to Program X. Company Bar also sets
up its own policies to protect the confidentiality its own up its own policies to protect the confidentiality its own
intellectual property it contributes to Program X. As part of the intellectual property it contributes to Program X. As part of the
agreement between Foo and Bar, they have agreed to mutually respect agreement between Foo and Bar, they have agreed to mutually respect
each other's policies. each other's policies.
Confidentiality policies can change over time. It is important to be
able to implement the changes without the need to update the data
object itself to reflect the change as finding all instances of the
data in an intrinsically impossible problem to solve. .
Frank is an employee of Company Foo. He has been assigned as a Frank is an employee of Company Foo. He has been assigned as a
design team leader on Program X and an individual contributor on design team leader on Program X and an individual contributor on
Program X integration. Frank wants to send some mail as a team Program X integration. Frank wants to send some mail as a team
leader to colleagues working on Program X in both Companies Foo and leader to colleagues working on Program X in both Companies Foo and
Bar. Bar.
Grace is an employee of Company Bar. She has also been assigned to Grace is an employee of Company Bar. She has also been assigned to
the design team of Program X. the design team of Program X.
When Frank sends the Email with Program X regulated content he must When Frank sends the Email with Program X regulated content he must
skipping to change at page 20, line 38 skipping to change at page 24, line 40
If Grace sends an email with Company Bar intellectual property, she If Grace sends an email with Company Bar intellectual property, she
must ensure recipients are authorized to read the contents under must ensure recipients are authorized to read the contents under
the agreement between Company Bar and Company Foo. the agreement between Company Bar and Company Foo.
When Frank sends a Program X Email he must ensure the following When Frank sends a Program X Email he must ensure the following
objectives: objectives:
(a) Only recipients who meet the Program X policy and or Company (a) Only recipients who meet the Program X policy and or Company
Foo's intellectual property protection policy can read the Email Foo's intellectual property protection policy can read the Email
(b) The recipients authenticates with an acceptable level of (b) Recipients authenticate with a identity assurance level of level
assurance (i.e. level 3 or above) 3 or above
(c) Recipients present any other attributes about themselves (c) Recipients present any other attributes about themselves
necessary to verify compliance with the applicable policies necessary to verify compliance with the applicable policies
(theirs program assignment, nationality, professional or (theirs program assignment, nationality, professional or
industry certifications, etc.) industry certifications, etc.)
(d) Recipients can verify the Email is from Frank to the level of (d) Recipients can verify the Email is from Frank to the level of
assurance as defined by the message policy (i.e. level 3 or identity assurance as defined by the message policy (i.e. level
above) 3 or above)
(e) Recipients can verify the Email has not been tampered with the (e) Recipients can verify the Email has not been tampered with the
level of assurance as defined by the message policy level of identity assurance as defined by the message policy
(f) Recipients are made aware that the message is a Program X Email (f) Recipients are made aware that the message is a Program X Email
and the contents can only be shared with other Program X workers and the contents can only be shared with other Program X workers
and/or the message contains Company Foo's intellectual property and/or the message contains Company Foo's intellectual property
The sequence of events Frank would use is as follows: The sequence of events Frank would use is as follows:
(1) Frank composes the Email and includes a Program X distribution (1) Frank composes the Email and includes a Program X distribution
list as a recipient. He include some information relation to list as a recipient. He include some information relation to
Program X. Frank also includes some information which is Company Program X. Frank also includes some information which is Company
skipping to change at page 22, line 11 skipping to change at page 26, line 11
Frank receives the reply from Grace. Frank is able to prove his Frank receives the reply from Grace. Frank is able to prove his
identity to the level requested by Grace and provides the requested identity to the level requested by Grace and provides the requested
attributes about himself to satisfy both the Program X export attributes about himself to satisfy both the Program X export
control, the Company Foo IP protection policies as well as the control, the Company Foo IP protection policies as well as the
Company Bar IP protection policies. Frank opens the Email. Company Bar IP protection policies. Frank opens the Email.
The policy also applies to messages forwarded by Frank and Grace The policy also applies to messages forwarded by Frank and Grace
because it contains information from Company Foo and Company Bar both because it contains information from Company Foo and Company Bar both
companies wants consistent policy enforcement on its information. companies wants consistent policy enforcement on its information.
After some time, Company Bar fails an audit to show they are
complying which all the requirements for Program X. As a result,
Company Foo updates its policies for Program X to remove company Bar
as an approved to access Program X data. Grace will no longer be able
to access the Program X email as she can no longer satisfy the
Program X policy requirements.
3.4.2 Regulated Email Requiring an Integrity Policy 3.4.2 Regulated Email Requiring an Integrity Policy
Company Foo has been awarded a contract to build some equipment Company Foo has been awarded a contract to build some equipment
(Program X). This equipment is regulated by the National Aviation (Program X). This equipment is regulated by the National Aviation
Authority (NAA) for Company Foo. The NAA requires strict procedures Authority (NAA) for Company Foo. The NAA requires strict procedures
at a number of significant events for Program X such as in the at a number of significant events for Program X such as in the
design, and maintenance of the Project X e.g. when a design is design, and maintenance of the Project X e.g. when a design is
complete and released to manufacturing. The sign of process requires complete and released to manufacturing. The sign of process requires
personal be suitability qualified and that the documentation needs to personal be suitability qualified and that the documentation needs to
be maintained for the service life of the project (25 years for be maintained for the service life of the project (25 years for
skipping to change at page 22, line 45 skipping to change at page 27, line 5
receives the sign off email. Grace responds and applies the sign-off receives the sign off email. Grace responds and applies the sign-off
policy to the email. The policy requires Grace to authenticate with policy to the email. The policy requires Grace to authenticate with
the required level of assurance, present attributes about herself, the required level of assurance, present attributes about herself,
her work effort assignments and professional qualifications to her work effort assignments and professional qualifications to
demonstrate compliance with the policy to send the message. The demonstrate compliance with the policy to send the message. The
message is signed to indicate Grace passed the policy. message is signed to indicate Grace passed the policy.
When Frank sends a Program X Sign Off Email the system must ensure When Frank sends a Program X Sign Off Email the system must ensure
the following objectives: the following objectives:
(a) Frank was authenticated to the level of assurance under the (a) Frank was authenticated to the level of identity assurance under
policy as the originator of the email the policy as the originator of the email
(b) Frank possessed the necessary attributes as required to (b) Frank possessed the necessary attributes as required to
authorize Frank to send the sign-off email authorize Frank to send the sign-off email
(c) The contents of the email are accurate to the level of assurance (c) The contents of the email are accurate to the level of integrity
required by the policy assurance required by the policy
(d) Frank was fully aware and intended to send the sign off email to (d) Frank was fully aware and intended to send the sign off email to
the level of assurance as required by the policy the level of identity assurance as required by the policy
(e) The state of Franks system was known to the level of assurance (e) The state of Franks system was known to the level of assurance
required under the policy to be free from agents which might required under the policy to be free from agents which might
interfere with the sign off process interfere with the sign off process
(f) Recipients can easily confirm over the lifetime as required by (f) Recipients can easily confirm over the lifetime as required by
the policy that Frank passed the policy without having to know the policy that Frank passed the policy without having to know
specifics of hat the policy entailed. specifics of what the policy entailed.
The sequence of events Frank would use is as follows: The sequence of events Frank would use is as follows:
(1) Frank receives the sign off request email. (1) Frank receives the sign off request email.
(2) Frank's replies to the email and completes the form data in the (2) Frank's replies to the email and completes the form data in the
email so show he is approving the sign-off email so show he is approving the sign-off
(3) Frank slicks the send button to send the email (3) Frank clicks the send button to send the email
(4) Frank receives a sign-off confirmation dialogue before the email (4) Frank receives a sign-off confirmation dialogue before the email
is sent where he has to confirm his intent is to approve the is sent where he has to confirm his intent is to approve the
sign off of the component. sign off of the component.
Franks system submits the decision request to send the sign-off Franks system submits the decision request to send the sign-off
email. His system is asked to provide data about Frank, the state of email. His system is asked to provide data about Frank, the state of
Franks system, and the data being authenticated. If Frank's passes Franks system, and the data being authenticated. If Frank's passes
the policy, his system receives a signed statement the message passes the policy, his system receives a signed statement the message passes
the policy which is attached to the email and the message sent. the policy which is attached to the email and the message sent.
skipping to change at page 24, line 31 skipping to change at page 28, line 39
verify compliance with the policies (e.g. their professional verify compliance with the policies (e.g. their professional
qualification, professional registration, affiliated healthcare qualification, professional registration, affiliated healthcare
facility and department) facility and department)
(e) Recipients can verify the Email is from the sender (Hanna) to (e) Recipients can verify the Email is from the sender (Hanna) to
the level of assurance as defined by the message policy (i.e. the level of assurance as defined by the message policy (i.e.
level 3 or above) level 3 or above)
(f) Recipients can verify the Email has not been tampered with the (f) Recipients can verify the Email has not been tampered with the
level of assurance as defined by the message policy level of assurance as defined by the message policy
(g) Recipients are made aware that the message is a Patient referral (g) Recipients are made aware that the message is a Patient referral
and contains sensitive patient data. workers. and contains sensitive patient data. workers.
The sequence of events Frank would use is as follows: The sequence of events Frank would use is as follows:
(1) Hanna composes the Email and includes Ida as a recipient. She (1) Hanna composes the Email and includes Ida as a recipient. She
includes the patient information, test results and comments in includes the patient information, test results and comments in
the Email the Email
(2) Hanna's Email client allows her to select a business context (2) Hanna's Email client allows her to select a business context
which is appropriate for her work. Hanna selects a Patient which is appropriate for her work. Hanna selects a Patient
Consultation context. Consultation context.
(3) Hanna selects the Patient Referral and Patient Consent decree (3) Hanna selects the Patient Referral and Patient Consent decree
policies from the list of available policies. policies from the list of available policies.
The Email client knows the protections to apply to the Email; to The Email client knows the protections to apply to the Email; to
encrypt and integrity-protect the message, the level of assurance encrypt and integrity-protect the message, the level of assurance
required for the recipient's identity and what recipient attributes required for the recipient's identity and what recipient attributes
are necessary to access the message. are necessary to access the message.
(4) Hanna clinks the send Email button. The client signs the Email (4) Hanna clinks the send Email button. The client signs the Email
using Hanna smart card. The Client then encrypted the message using Hanna smart card. The Client then encrypted the message
and sends it to his Email server. and sends it to his Email server.
skipping to change at page 25, line 22 skipping to change at page 29, line 31
certificate. certificate.
(7) Ida uses her smart card to open the message. She sees the (7) Ida uses her smart card to open the message. She sees the
message is marked with both the Patient Referral and Sensitive message is marked with both the Patient Referral and Sensitive
Patient Data policies Patient Data policies
3.7 Regulated Email Compliance Verification 3.7 Regulated Email Compliance Verification
TBD TBD
3.8 Email Pipeline Inspection 3.8 Email Pipeline Inspection
TBD add pre-auth and regular access
Organizations have a huge incentive to want to some level of Organizations have a huge incentive to inspect on emails entering or
inspection on all mails entering or leaving the organization. This leaving the organization. This is desired for many different
is desired for many different reasons. Inspection of mail leaving an reasons. Inspection of mail leaving an organization is targeted
organization is targeted towards making sure that it does not leak towards making sure that it does not leak confidential information.
confidential information. It also behooves them to check that they It also behooves them to check that they are not a source of
are not a source of malicious content or spam. Inbound mail is malicious content or spam. Inbound mail is checked primarily for
checked primarily for malicious content, phishing attempts as well as malicious content, phishing attempts as well as spam. For domain with
spam. a high volume of messages there is a strong need to process email
with minimal overhead. Such domains may mandate that they be pre-
authorized to process an email due to the overhead a per-message call
to an external service would add to message processing.
Company Foo receives Email from the Internet. Company Foo has a Company Foo has a policy to scan all inbound and outbound email to
policy to scan inbound Email with a view to remove inappropriate or ensure it is free from malware. Company Foo also want to ensure email
malicious content. The scanning of inbound Email for Company Foo can is not spam. Company Foo can own their own scanning servers or it may
happen on their own servers or it may be outsourced to a third party. be outsourced to a third party service. Company Foo wants to ensure
This works fine as long as the Email is not encrypted, however in that its policy of scanning also appliers to Plasma protected email.
that event the server will have a policy on how to deal with
encrypted mail. For some companies, encrypted mail will be passed
through and virus detection software on the recipient's client will
be relied on. In other circumstances, the decryption key used by the
recipient is shared with the gateway software so that it can decrypt
the message.
The ability to decrypt and check the content for malicious content is The ability to decrypt and check the content for malicious content is
highly desirable even when a PLASMA encrypted Email message is highly desirable even when a PLASMA encrypted Email message is
encountered. The methods that this can be dealt with using on of the encountered. The methods that this can be dealt with using on of the
following methods: following methods:
1. The scanning server authenticates to the policy server as the 1. When a Company Foo client requests to send a Plasma email from a
entity doing virus and malware scanning. If the policy has PDEP, the PDEP is able to check to see if the policy allows email
specific attributes that allow for access to be granted to such a content inspection by MTA, and if it does, that Company Foo has an
outbound email scanning, and that the scanning servers meet the
policy requirements. It is abbe to pre-authorize the Company Foo
email scanning servers to access the email.
2. The scanning MTA authenticates to the PDEP as an entity doing
virus and malware scanning on a protected message. If the PDEP has
specific policy that allow for access to be granted to such a
scanning service, the appropriate decryption keys will be released scanning service, the appropriate decryption keys will be released
and the server will scan the mail and take appropriate action. and the server will scan the mail and take appropriate action.
2. The policy server is configured with information about the 3. The policy server is configured with information about the
server took various gateways (both internal and external) and has server took various gateways (both internal and external) and has
certificates for the known gateways. The policy server can then certificates for the known gateways. The policy server can then
return a normal X.509 recipient info structure (lockbox) to the return a normal X.509 recipient info structure (lockbox) to the
sender of the message for direct inclusion in the recipient info sender of the message for direct inclusion in the recipient info
list. This allows normal processing by the scanning software list. This allows normal processing by the scanning software
without the necessity to stop and query the policy server for without the necessity to stop and query the policy server for
keying information at a cost of needing wider configuration. keying information at a cost of needing wider configuration.
3. If the scanning server cannot gain access to the decrypted 4. If the scanning server cannot gain access to the decrypted
content using one of the two proceeding methods, it either passes content using one of the two proceeding methods, it either passes
the encrypted mail on the the recipient(s) without scanning it or the encrypted mail on the the recipient(s) without scanning it or
it rejects the mail. This decision is based on local policy. If it rejects the mail. This decision is based on local policy. If
the message is passed to the recipient, then the necessary scanning the message is passed to the recipient, then the necessary scanning
either will not be done or needs to be done on the client's system either will not be done or needs to be done on the client's system
after the message has been decrypted. after the message has been decrypted.
3.9 Scalable Decision Making 3.9 Distribution List Expansion
A distribution list is a function of an MTA that allows a user to
send an email to a group of recipients without having to address all
the recipients individually. Membership of the DL may be confidential
so the sender may not know all the recipients. THe DL may be
maintained by an external organization. Since a DL is identified by
an email address, the user may be unaware they are sending to a DL.
Plasma polices may have the list of recipients as a parameter
therefor the fact the message is being process by the distribution
list means the MTA processing the message needs to update the policy
to allow the new recipients to access the message. Organization may
also require inbound scanning of email and have therefore published
keys to enable pre-authentication of the MTA by the sender to
expedite processing. For both scenarios the DL MTA has to notify the
Plasma server that it is adding recipients to the message and supply
the list of new recipients. The Plasma server can then take
appropriate action on the message token and return an updated token
if required.
3.10 Scalable Decision Making
Collaboration involvers working with partners and suppliers. These Collaboration involvers working with partners and suppliers. These
collaborations may be short or long lived, with small or very large collaborations may be short or long lived, with small or very large
number of participants. Organizations therefore need flexibility in number of participants. Organizations therefore need flexibility in
deployment and scaling. Organizations do not want to be locked into deployment and scaling. Organizations do not want to be locked into
having to provide capacity themselves. Senders would be happy to having to provide capacity themselves. Senders would be happy to
delegate decisions to partners providing those decisions use the sets delegate decisions to partners providing those decisions use the sets
of rules they define for their data. Likewise partners would be happy of rules they define for their data. Likewise partners would be happy
to leverage their local decision capacity providing they don't have to leverage their local decision capacity providing they don't have
to duplicate rules themselves, and can simply and easily use policies to duplicate rules themselves, and can simply and easily use policies
published by their partners. Also organization may want to use cloud published by their partners. Also organization may want to use cloud
based decision services as a cost effective way to add capacity and based decision services as a cost effective way to add capacity and
to be able to respond to transient capacity fluctuations. to be able to respond to transient capacity fluctuations.
todo rest of scenario Company Foo has been awarded a contract to build some equipment
(Program X). The equipment is covered by export control which
requires information only be released to authorized recipients under
the terms of the export control licence. Company Bar is a foreign
subcontractor to company Foo working on Program X. Company Foo sets
up some business rules for access to program X data to ensure
compliance with the export control licence requirements. Company
Foo also set up separate rules to cover the confidentiality of its
intellectual property contributed to Program X. Company Bar also sets
up its own policies to protect the confidentiality its own
intellectual property it contributes to Program X. As part of the
agreement between Foo and Bar, they have agreed to mutually respect
each other's policies.
3.10 Related scenarios The Program Manages for Program X at Companies Foo and Bar agree a
series of roles which are used to manage personal and their assigned
policy groups. The policy administrators for Company Foo and Bar
respectively publishes the roles and a policy collection for each
role. There are rules associated with the policy collection, for
example every roles uses the Program X policies published by Company
Foo. Employees from Company Foo also get the company Foo Intellectual
Property polices for that roles, whereas employees from company Bar
get the company Bar intellectual property polices for Program X.
Company Foo has also decided to allow enforcement of Program X
policies by decision engines in both Company Foo and Company Bar.
Company Foo has also decided to use a cloud decision engine for
Program X to allow lower cost capacity and scaling. Company Foo is
able to add new instances of the cloud decision services as the
program scales up and more uses start working on the program. Each
decision engine dynamically discovers the policies it needs from the
set published by Company Foo and Company Bar. Both company Foo and
Company bar can add new polices to the policy collections at any time
and they are dynamically discovered by all the policy decision
engines
3.11 Related scenarios
There are other scenarios which are related to the Email cases There are other scenarios which are related to the Email cases
because they would be subject to the same policy requirements. Email because they would be subject to the same policy requirements. Email
allows users to create content and transport it to a set of allows users to create content and transport it to a set of
recipients. You can perform similar actions with other formats such recipients. You can perform similar actions with other formats such
as documents and instant messages. Policy is agnostic to the as documents and instant messages. Policy is agnostic to the
underlying technology therefore if an organization has a policy underlying technology therefore if an organization has a policy
relating to a type of information, then that policy would apply to relating to a type of information, then that policy would apply to
the same content in an Email, a document an instant message, etc. the same content in an Email, a document an instant message, etc.
3.10.1. Document Protection 3.11.1. Document Protection
This scenario is very similar to 3.4 and 3.6 above. The difference This scenario is very similar to 3.4 and 3.6 above. The difference
is that the information being generated is in the form of a document is that the information being generated is in the form of a document
not an Email. It could be as part of an ad-hoc sharing or a not an Email. It could be as part of an ad-hoc sharing or a
regulated sharing or information. regulated sharing or information.
Frank is an employee of Company Foo. He has been assigned to Program Frank is an employee of Company Foo. He has been assigned to Program
X. Grace is an employee of Company Bar. She has been assigned to X. Grace is an employee of Company Bar. She has been assigned to
Program X. Frank creates a document for the program. He also Program X. Frank creates a document for the program. He also
includes some Company Foo IP in the document. When Frank creates the includes some Company Foo IP in the document. When Frank creates the
skipping to change at page 28, line 28 skipping to change at page 33, line 46
requirements to the document. Grace saves the updated document to requirements to the document. Grace saves the updated document to
the same location on the portal. the same location on the portal.
Frank sees that Grace has updated the document on the portal. Frank Frank sees that Grace has updated the document on the portal. Frank
is able to prove his identity to the level requested by both the is able to prove his identity to the level requested by both the
Company Foo and company Bar policies and provides the requested Company Foo and company Bar policies and provides the requested
attributes about himself to satisfy both the Program X export attributes about himself to satisfy both the Program X export
control, the Company Foo IP protection policies as well as the control, the Company Foo IP protection policies as well as the
Company Bar IP protection policies. Frank opens the document. Company Bar IP protection policies. Frank opens the document.
3.10.2 Instant Message Protection 3.11.2 Instant Message Protection
This scenario is very similar to 3.4 and 3.6 above. The difference This scenario is very similar to 3.4 and 3.6 above. The difference
is that the information being generated is in the form of a instant is that the information being generated is in the form of a instant
message not an Email. It could be as part of an ad-hoc sharing or a message not an Email. It could be as part of an ad-hoc sharing or a
regulated sharing or information. regulated sharing or information.
Frank is an employee of Company Foo. He has been assigned to Program Frank is an employee of Company Foo. He has been assigned to Program
X. Grace and Hank are employees of Company Bar and also has been X. Grace and Hank are employees of Company Bar and also has been
assigned to Program X. Frank want to discuss an urgent topic with assigned to Program X. Frank want to discuss an urgent topic with
Grace and Hank. The topic necessitates discussion of Company Foo IP. Grace and Hank. The topic necessitates discussion of Company Foo IP.
skipping to change at page 30, line 33 skipping to change at page 36, line 33
ensure the right overall direction for Plasma as each part of ensure the right overall direction for Plasma as each part of
the work proceeds, a high level data model is documented here to the work proceeds, a high level data model is documented here to
act as a guide. While this is technically informative to the act as a guide. While this is technically informative to the
developments of each individual component, it is normative to developments of each individual component, it is normative to
the work overall. the work overall.
This Data Centric Security model is based on a well established This Data Centric Security model is based on a well established
set of actors for policy enforcement used elsewhere [RFC3198] set of actors for policy enforcement used elsewhere [RFC3198]
[XACML-core]. [XACML-core].
4.1 Vocabulary Figure 1 shoes the relationship between the actors.
These terms are the same as used by RFC3198. While the roles are
fundamentally the same, there are some minor differences in the
responsibilities of each actor with models such as XACML.
These terms are taken included for the convenience of the
reader:
Policy: The policy has two basic forms. A human readable form
which defines a set of high level requirements. These human
readable policies may be, for example, in the form of legislation,,
or a legal contract. These high level policies are then translated
into technical policies for implementation. Policies may stipulate
many forms of requirements such as data protection, access control,
integrity, data origination, data retention, etc.
Policy Collection: A collection of one or more policies. The
policy collection may also defines the logical relationship between
the policies
Policy Administration Point (PAP): The system entity that creates,
maintains and publishes policies or policy collections. The
policies define the rules, their conditions and actions associated
with the policy.
Policy Decision and Enforcement Point (PDEP): The system entity
that evaluates the policy criteria published by a PAP, using
attributes supplied by a PIP to render decisions from request made
by DRs.
Policy Information Point (PIP): A service with issues assertions
about subjects or the subject's environment e.g. a SAML Security
Token Service. This model supports both front end and back end
exchange of assertions between the PIP and the PDEP. Attributes can
be distributed directly between the PIP and the PDEP (Backbend
Attribute Exchange;BAE). Alternatively attributes may be
distributed via the DR (Front End Attribute Exchange; FAE) There
are two types of PIP based on the types of attribute the PIP would
assert about the subject. A Identity Provider (IdP) PIP will issue
authentication attributes e.g. information about how and when the
subject authenticated to the IdP. An IdP may also issue attributes
about the subject themselves e.g. their full name, age or
citizenship. An attribute provider (AtP)PIP only issues attributes
about the subject or the subject's environment.
Decision Requester (DR): The service responsible for making policy
decision requests to the PDEP. In this model the policy decision is
enforced by the PDEP by its control of cryptographic keys. The DR
enforces any obligations the PDEP may require such as signing or
encryption of the data, generating audit events etc. An DR is
distinct from a Policy Enforcement Point in other models such as
XACML in that an DR is not by default trusted with the clear text
data. Policy enforcement is preformed by the PDEP. An DR may
establish trust by presentation of attributes about itself and its
environment to show it is trustworthy.
We additional make use of the following terms:
Attribute Request/Issuance: The act of a client requesting and
obtaining a set of attributes for a subject. The issuance of
attributes will itself be controlled by policy and thus recursively
embeds this same picture in that process. For simplicity we use
SAML as the format for both requesting and receiving attributes and
would suggest the use of the SAML 2.0 Assertion Query and Request
Protocol as one method for requesting the necessary attributes.
The attributes can be requested either by the AR (front end
attribute exchange) or the PDEP (back end attribute exchange).
Content Protection Request/Response: The protocol to be run by the
DR to get the set of decisions and information required to
successfully create and encode a data block with appropriate
labeling. This protocol is part of the work to be defined by this
group.
Content Consumption Request/Response: The protocol to be run by
the DR to obtain the permissions and information needed to decode
and access a data block with appropriate labeling. This protocol
is part of the work to be defined by this group.
Content Distribution: Can be any of a number of methods by which
the content is transmitted from the Content Creator to the Content
Consumer. These methods include, but are limited to: Email, FTP,
XMPP, HTTP and SneakerNet.
Role: A role is a policy collection that has an associated textual
name. A role in this context is not to be confused with a role in
role-based policies, while the concepts are similar they are not
identical.
Role Set: A collection of one or more roles.
Policy Identifier: Is the tag that is used to identify a policy.
For the purposes of our document we are focusing on two different
types of policy identifiers. Object Identifiers (OIDs) are what
are currently used in many security policy systems and are the only
method of policy identification supported by ESS security labels.
Additionally we will support URIs as policy identifiers as they
provide a more user friendly method of uniquely identify a policy
and allow discovery of the policy.
Policy Label: The data structure which holds one or more policy
identifiers and their logical relationship.
Figure 1 shoes the relationship between the actors.
------------------ ------------------
| | | |
| Policy | | Policy |
| Administration | | Administration |
| Point | | Point |
| | | |
------------------ ------------------
| |
----------------- | ----------------- ----------------- | -----------------
skipping to change at page 34, line 41 skipping to change at page 38, line 41
be suitable. If the PDEP requires higher assurance, then holder of be suitable. If the PDEP requires higher assurance, then holder of
key tokens over SSL would be required. key tokens over SSL would be required.
o This model also supports Capability-Based Access Control (CBAC) o This model also supports Capability-Based Access Control (CBAC)
where security tokens represent a capability to meet a policy. Once where security tokens represent a capability to meet a policy. Once
a subject has proven compliance with a policy, they can be issued a a subject has proven compliance with a policy, they can be issued a
capability token. The client can subsequently present this capability token. The client can subsequently present this
capability token in lieu of a token or tokens with the set of capability token in lieu of a token or tokens with the set of
subject attributes. The net result is the model can transition to subject attributes. The net result is the model can transition to
a Capability Based Access Control because the capability token is a Capability Based Access Control because the capability token is
an unforgeable token of compliance with a policy. The token can be an un-forgeable token of compliance with a policy. The token can be
used with any resource tagged with the same policy. used with any resource tagged with the same policy.
o Plasma has a baseline of a secure transport between the DR and o Plasma has a baseline of a secure transport between the DR and
the PDEP. One of the decisions the PDEP has to make is the level of the PDEP. One of the decisions the PDEP has to make is the level of
assurance on the release of the DEK to the subject. For example the assurance on the release of the DEK to the subject. For example the
PDEP can release a clear text DEK over the secure transport to the PDEP can release a clear text DEK over the secure transport to the
DR. Alternatively the could require the production of a high DR. Alternatively the could require the production of a high
assurance X.509 encryption certificate as a subject attribute to assurance X.509 encryption certificate as a subject attribute to
generate an encrypted DEK. generate an encrypted DEK.
skipping to change at page 38, line 48 skipping to change at page 42, line 48
Figure 2 Options For Trussed Actors With Data. Figure 2 Options For Trussed Actors With Data.
When drawing a line where the actors in the model are full trusted When drawing a line where the actors in the model are full trusted
with the clear text data there are three possibilities (see figure with the clear text data there are three possibilities (see figure
2). 2).
Figure 2a shows the full trust line between the user application and Figure 2a shows the full trust line between the user application and
the Policy Enforcement Point(PEP). This is the model for current the Policy Enforcement Point(PEP). This is the model for current
standard access control e.g. XACML [XACML-core]. In 2a, the PEP has standard access control e.g. XACML [XACML-core]. In 2a, the PEP has
full access to the clear text data. It makes decision requests to the full access to the plain text data. It makes decision requests to the
PDEP and if the decision is allow the PEP releases the data to the PDP and if the decision is allow the PEP releases the data to the
application. To use fig 2a for secure Email would require every MTA application. To use fig 2a for secure Email would require every MTA
and MUA to act as a PEP so to be fully trusted with clear text data and MUA to be fully trusted with plain text data which is
which is impossible. impossible.
Figure 2b shows the full trust line between the PDEP and the DR. In Figure 2b shows the full trust line between the PDEP and the DR. In
2b, the DR only has cipher text data. The data is encrypted with a 2b, the DR only has cipher text data. The data is encrypted with a
content encryption key (CEK) and the PDEP has the CEK. THe PDEP content encryption key (CEK) and the PDEP has the CEK. THe PDEP
releases the CEK to the end user application when access is granted. releases the CEK to the end user application when access is granted
This mode is viable for secure Email as either the MTA or the MUA can so the application can recover the plain text. This mode is viable
act as a DR. for secure Email as it does not require the MTA to be trusted wit the
plain text data and either the MTA or MUA can act as a DR.
In figure 2c, no actor is given full trust. When the data is In figure 2c, no actor is given full trust. When the data is
encrypted, the CEK is encrypted for each recipient just as S/MIME encrypted, the CEK is encrypted for each recipient just as S/MIME
does today. The encrypted CEKs are given to the PDEP and the PDEP does today. The encrypted CEKs are given to the PDEP and the PDEP
releases the encrypted CEK when access is granted. This mode is also releases the encrypted CEK when access is granted. This mode is also
viable for secure Email as the sender can use either conventional viable for secure Email as the sender can use either conventional
Public key cryptography or Identity Based Encryption[RFC5408] to Public key cryptography or Identity Based Encryption[RFC5408] to
protect the CEK for each recipient. protect the CEK for each recipient.
Author Note: Clarify requirements for exchange of KEK 4.1 Plasma Client Server Key Exchange Level of Assurance
There are a number of mechanisms by which a client and servers can
exchange keys. As a baseline, Plasma is establishing a secure
transport between the client and server. However the client may be a
proxy acting on behalf of the subject, therefore transporting a clear
text key over the TLS transport would expose the key to the proxy.
There also may be a proxy at the server which is terminating the TLS
transports and forwarding the requests to another server which would
mean a clear text key over the transport would be exposed to the
server proxy. Policies may require a higher level of assurance that
the key is not exposed to unauthorized principals. This requires
encrypting the KEK for the subject before transport. This would
require the client or the server to provide a public key to the other
party to be used to protect the KEK before sending over the secure
transport.
4.2 Policy Data Binding 4.2 Policy Data Binding
There are three ways to bind policy to data. There are three ways to bind policy to data.
o By value. This is where a copy of the machine readable rule set o By value. This is where a copy of the machine readable rule set
is directly associated with the data e.g. where a file system has a is directly associated with the data e.g. where a file system has a
Access Control List for the file or directory or where a rights Access Control List for the file or directory or where a rights
management agent has embedded a copy of the policy expressed in a management agent has embedded a copy of the policy expressed in a
policy expression language in the rights protects data. When an policy expression language in the rights protects data. When an
skipping to change at page 39, line 37 skipping to change at page 44, line 4
is directly associated with the data e.g. where a file system has a is directly associated with the data e.g. where a file system has a
Access Control List for the file or directory or where a rights Access Control List for the file or directory or where a rights
management agent has embedded a copy of the policy expressed in a management agent has embedded a copy of the policy expressed in a
policy expression language in the rights protects data. When an policy expression language in the rights protects data. When an
access request is made to the data, the PDEP compares the access access request is made to the data, the PDEP compares the access
request to the policy on the data itself. request to the policy on the data itself.
o By reference. This is where a reference to the policy is directly o By reference. This is where a reference to the policy is directly
associated with the data. e.g. a URI or a URN which identifies the associated with the data. e.g. a URI or a URN which identifies the
policy to be enforced or points to where the policy is published. policy to be enforced or points to where the policy is published.
For example with S/MIME the ESS label identifies the applicable For example with S/MIME the ESS label identifies the applicable
policy by an OID. When an access request is made to the data, the policy by an OID. When an access request is made to the data, the
PDEP finds the policy based on the identifier and then compares the PDEP finds the policy based on the identifier and then compares the
access request to the referenced policy. access request to the referenced policy.
o By inference. This is where the policy has a target description o By inference. This is where the policy has a target description
in terms of characteristics of the sets of data resources the in terms of resource attributes the policy applies to. When an
policy applies to. When an access request is made, the set of access request is made, a set of attributes describing the resource
policies are evaluated at run time to determine the set of policies which is the subject of the access request are included in the
to apply. For example when you author a XACML policy, you also request by a PEP. The PDP then evaluates the set of policies in its
policy store to determine the set of policies to apply to the
request. For example when you author a XACML policy, you also
define a target for the policy. When an access request is made to define a target for the policy. When an access request is made to
the data, the PDEP finds the policy using the set of attributes of the data, the PDP finds the policy using the set of attributes of
the resource looking for any policies that match the target the resource looking for any policies that match the target
description associated with the policy. It then compares the access description associated with the policy. It then compares the access
request to the identified policy. request to the identified policy.
The chief strength of binding policy by value is its simplicity. The The chief strength of binding policy by value is its simplicity. The
policy is local to the data can can easily and quickly be read. The policy is local to the data can can easily and quickly be read. The
chief weakness in binding policy by value is maintaining policy over chief weakness in binding policy by value is maintaining policy over
time. Many policies have a multi-year life span and during the course time as binding by value results in the policy being replicated for
of that time there is a very high probability that the policy would every instance of data the policy is applied to. Many policies have a
need to be updated. Given the high number of copies, it has proven to multi-year life span and during the course of that time there is a
be an very costly and imperfect process both from an enforcement and very high probability that the policy would need to be updated. Given
audit perspective. This process is complicated by the fact that the high number of copies, it has proven to be an very costly and
because only the result is stored and not an identifier, it is hard imperfect process both from an enforcement and audit perspective.
to identify the policy which has to be updated. This process is complicated by the fact that because only the result
is stored and not an identifier, it is hard to identify the policy
which has to be updated.
The chief strength of binding by names is once bound to the data the The chief strength of binding by names is once bound to the data the
association with the policy travels with the data. The chief weakness association with the policy travels with the data. The chief weakness
in binding by name is it requires the reference to be strongly bound in binding by name is it requires the reference to be strongly bound
to the data. This is possible using cryptography but then process of to the data. This is possible using cryptography but then process of
persisting the binding impacts the storage format. This can break persisting the binding impacts the storage format. This can break
backwards compatibility. backwards compatibility.
The chief strength of binding by description is it can be applied to The chief strength of binding by inference is it can often be applied
data without impacting the storage format. The chief weakness in to data without impacting the storage format providing the data
binding by description is the reliability of the matching. Any already has resource attributes such as with a SQL table. The chief
matching process must have a false positive and falsie negative rate. weakness in binding by inference is the reliability of the matching
This rate has to be evaluated on a case by case basis over time as it in in part due to the assumption the necessary policy is in the
can change making compliance expensive. The set of available policy store. Any matching process must have a false positive and
attributes also varies with different data types e.g. structured falsie negative rate. This rate has to be evaluated on a case by case
database information has a rich set of attributes whereas documents basis over time as it can change making compliance expensive. The set
and files have a poor set of attributes. This inconsistently over of available attributes also varies with different data types e.g.
available attributes impacts matching reliability. The resultant set structured database information has a rich set of attributes whereas
of policies for a policy target is also dependent on the correctness unstructured data such as documents and files have a poor set of
of the set of policies evaluated. Its also impossible to detect if a resource attributes. This inconsistently over available attributes
policy is missing from the policy store which again would mean impacts matching reliability. The resultant set of policies for a
incorrect policy enforcement policy target is also dependent on the correctness of the set of
policies evaluated. Its also impossible to detect if a policy is
missing from the policy store which again would mean incorrect policy
enforcement
This model is choosing to use binding by name because we need to The Plasma model is choosing to use binding by name because we need
encrypt the data which means we will impacting the storage format to encrypt the data which means we will impacting the storage format
anyway which negates the main weakness of binding my name. We get the anyway which negates the main weakness of binding my name. We get the
reliability of policy enforcement which is independent of location reliability of policy enforcement which is independent of location
and we get low maintenance since we are only storing a reference to and we get low maintenance since we are only storing a reference to
the policy and not the policy wit the data.. the policy and not the policy with the data..
4.3 Content Creation Workflow 4.3 Content Creation Workflow
The Content Creation DR bootstraps itself via the following sequence The Content Creation DR bootstraps itself via the following sequence
of events: of events:
(1) The content creation DR is configured with the set PIP's and (1) The content creation DR is configured with the set PIP's and
PDEP's it trusts. PDEP's it trusts.
(2) The content creation DR summits a request to all the trusted (2) The content creation DR summits a request to all the trusted
PDEPs for the set of roles it allows for the subject. The PDEPs for the set of roles it allows for the subject. The
subject is authenticated and authorized for the roles via subject is authenticated and authorized for the roles via
attributes from the PIP. The PIP attributes can be obtained by attributes from the PIP. The PIP attributes can be obtained by
the PDEP either via front-end (related to the PDEP from the PIP the PDEP either via front-end (related to the PDEP from the PIP
via the subject) or back-end (direct exchange between the PDEP via the subject) or back-end (direct exchange between the PDEP
and the PIP) processing. and the PIP) processing.
(3) The content creation DR receives a list of roles the PDEP can (3) The content creation DR receives a list of roles the PDEP can
configured for the subject configured for the subject
skipping to change at page 42, line 26 skipping to change at page 46, line 50
(E) The DR obtains the missing attributes requested by the PDEP (E) The DR obtains the missing attributes requested by the PDEP
and sends them to the PDEP and sends them to the PDEP
(F) Once the PDEP has a complete set of attributes, and the (F) Once the PDEP has a complete set of attributes, and the
attribute values match those required under the access policy, attribute values match those required under the access policy,
the PDEP releases the CEK to the DR along with a TTL which the PDEP releases the CEK to the DR along with a TTL which
defines how long the DR can use the CEK before it must discard defines how long the DR can use the CEK before it must discard
the CEK and reapply for access. the CEK and reapply for access.
(G) Once the DR has the CEK it decrypts the information. It caches (G) Once the DR has the CEK it decrypts the information. It caches
the CEK until the TTL expires. the CEK until the TTL expires.
4.5 Internet Facing Plasma Servers 4.5 Plasma Proxy Servers
There are two separate use cases for Plasma Proxy servers. Forward
proxy use cases where the Plasma client needs to connect to a Plasma
server outside its organization and reverse proxy use cases where
Plasma clients outside an organization, need to connect to a Plasma
server.
Plasma services will need to be Internet addressable to service A client has no control over senders creating Plasma email and
requests from DR's outside the organization network. Since the Plasma sending to them. Malicious sender can craft harmful payloads and
service has sensitive cryptographic keys, it would be unwise to host protect it in a Plasma envelope. Therefore a Plasma clients needs a
those on an server directly connected to the Internet. The simplest policy to determine the set of Plasma server they are willing to
configuration (a) would be to have a reverse web proxy in the DMZ in interact with. This can be as a local policy which is pushed down to
front of the Plasma server. Since Plasma is using TLS with channel every client. An alternate approach is to have a forward proxy manage
binding, the proxy has a limited function. The Plasma protocol is a the policy on behalf of the client. A forward proxy would eliminate
series of requestresponse messages, so it can be implemted like other the need to push policy about the set of trusted Plasma server by
store and forward message based services (b) e.g. SMTP, with an mediating the connection requests from the plasma clients to the
Internet facing server would terminate the TLS from the external DRs, plasma servers. The forward proxy could be a server belonging to the
ensure messages are not malformed and scan for malicious content, client organization or a cloud service.
before relaying messages to a full Plasma server further inside the
network.
Internet | DMZ | Intranet Internet | DMZ | Intranet
| | | |
| | | |
| --------------- | --------------- | | ---------------
| | | | | | | | | |
TLS | | Reverse | | TLS | Full | TLS | | TLS | Plasma |
----------|------|-------------|----|------| Plasma | ----------|<------------------------|------| Client |
| | Web | | | Server | | | | |
(a) | | ---------------
no proxy | |
| |
| |
| --------------- | ---------------
| | | | | |
TLS | | Forward | | TLS | Plasma |
----------|<-----| Plasma |<---|------| Client |
| | Proxy | | | |
(b) | | | | ---------------
Forward | --------------- |
Proxy | |
(a) | | Proxy | | | | Forward Plasma Proxy
| | | | | TLS Keys |
| --------------- | | Message |
| | | Encryption |
| | | Keys |
| | | |
| | ---------------
| |
| --------------- | ---------------
| | | | | |
TLS | | Proxy | | TLS | Full |
----------|------| Plasma |----|------| Plasma |
| | Server | | | Server |
(b) | | | | | |
| | TLS keys | | | TLS Keys |
| | | | | Message |
| --------------- | | Encryption |
| | | Keys |
| | | |
| | ---------------
| |
| |
For the reverse proxy case, Plasma servers will need to be Internet
addressable to service Plasma requests from DR's outside the
organization. Since the Plasma service has sensitive cryptographic
keys used to protect the message CEKs, it would be unwise to host
those directly connected to the Internet. The simplest possible
configuration (a) would be to have a passive reverse proxy in front
of the Plasma server. Since Plasma is using TLS with channel binding,
the proxy has a limited function and would be only able filter based
on IP addresses. The Plasma protocol is a series of requestresponse
messages, so an active reverse proxy can be implemented like other
store and forward message based services (e.g. SMTP), with an
Internet facing server which would terminate the TLS from the
external DRs, ensure DR can authenticate the TLS connection. Because
the active proxy terminates the TLS session, it can scan submitted
messages to ensure they are not malformed and are free from malicious
content before relaying messages to a full Plasma server further
inside the network for processing of the request.
Internet | DMZ | Intranet
| |
| |
| --------------- | ---------------
| | | | | |
TLS | | Passive | | TLS | Full |
----------|------|-------------|----|----->| Plasma |
| | Reverse | | | Server |
| | Proxy | | | |
(a) | | | | | |
| --------------- | | TLS Keys |
| | | Message |
| | | Encryption |
| | | Keys |
| | | |
| | ---------------
| |
| --------------- | ---------------
| | | | | |
TLS | | Active | | TLS | Full |
----------|----->| Reverse |----|----->| Plasma |
| | Proxy | | | Server |
(b) | | | | | |
| | TLS keys | | | TLS Keys |
| | | | | Message |
| --------------- | | Encryption |
| | | Keys |
| | | |
| | ---------------
| |
| |
Reverse Plasma Proxy
4.6 Policy Types 4.6 Policy Types
Policies range from very simple to very complex. Policies have Policies range from very simple to very complex. Policies have
dependencies not only on the technical implementation of the software dependencies not only on the technical implementation of the software
but on the range of attributes a PIP would would issue to subjects. but on the range of attributes a PIP would would issue to subjects.
This is likely constrained by the physical procedures a PIP would This is likely constrained by the physical procedures a PIP would
support to capture and verify the information about the subject. To support to capture and verify the information about the subject. To
manage this range of requirements, this model uses type types of manage this range of requirements, this model uses two type types of
policy. policy.
4.6.1 Basic Policy 4.6.1 Basic Policy
Basic policy is intended to be universally usable by using a small Basic policy is intended to be universally usable by using a small
fixed set of attributes. For example, basic policy is intended to be fixed set of attributes. For example, basic policy is intended to be
equivalent to sending encrypted Email with S/MIME today. It is a equivalent to sending encrypted Email with S/MIME today. It is a
simple policy that authenticated recipients of the Email get access simple policy that authenticated recipients of the Email get access
to the message. Its intended target is simple scenarios involving to the message. Its intended target is simple scenarios involving
consumers and small businesses who are using public PIP which issue a consumers and small businesses who are using public PIP which issue a
limited set of attributes. It is expected that all Plasma clients and limited set of attributes. It is expected that all Plasma clients and
commercial IdP would be capable of supporting basic policy due to commercial IdP would be capable of supporting basic policy due to
their simplicity and basic attribute set. their simplicity and basic attribute set required by basic polices.
As the available set of attributes increases over time, later
standards may define more basic polices which a bigger set of
attributes types.
4.6.2 Advanced Policy 4.6.2 Advanced Policy
Advanced policy is intended to be used where one or more arbitrary Advanced policy is intended to be used where one or more arbitrary
policies are required on the content . It is intended to target more policies are required on the content. It is intended to target more
complex scenarios such as content with regulated information or complex scenarios such as content with regulated information or
content subject to other organization and contractual policies. The content subject to other organization and contractual policies. The
input set of attributes is defined by the policies and can be either input set of attributes is defined by the policies are in theory
primordial or derived attributes or both. Multiple policies have a unbounded and can be either primordial such as date of birth or
logical relationship e.g. they can be AND or ORed together. It is not derived attributes such as age or both. A data object may require
expected that all Plasma clients support advances policy. multiple policies and any instance of multiple policies requires a
logical relationship between the polices e.g. they can be AND or ORed
together. It is not expected that all Plasma clients support the rich
set of attributes necessary for advances policy.
5. Message Protection Requirements 5. Message Protection Requirements
5.1. General Requirements 5.1. General Requirements
Protected content MUST be where the content is confidential, Confidentiality policy protected data MUST be where the data is
integrity protected AND provides data origination. confidential, integrity protected AND provide data origination
authentication and recipients are allowed to alter the data.
Every authentication has a level of assurance associated with it Integrity protected is where the data MUST be integrity protected
depending on attributes such as the identity checks made about the AND provide data origination authentication and recipients are NOT
subject and the authentication technology used. The authentication allowed to alter the data.
of content creator and content consumers MUST support the multiple
levels of identity assurance framework. (see scenarios 3.1, 3.2, 3.3 Every authentication has a level of identity assurance associated
and 3.4) with it depending on attributes such as the identity checks made
about the subject and the authentication technology used by the
subject. The authentication of content creator and content consumers
MUST support the multiple levels of identity assurance framework.
(see scenarios 3.1, 3.2, 3.3 and 3.4)
The specifics of every possible authentication mechanism or every The specifics of every possible authentication mechanism or every
detail about how the subject's identity was proofed by the IdP cannot detail about how the subject's identity was proofed by the IdP cannot
be known to the DR and PDEP, therefore the specifics of how sender or be known to the DR and PDEP, therefore the specifics of how sender or
recipient achieve the required level of identity assurance MUST be recipient achieve the required level of identity assurance MUST be
abstracted from the PDEP and DR by use of a simple numeric scale ( abstracted from the PDEP and DR by use of a simple numeric scale (
e,g, 0-4, or 1-6) liked to an identity assurance framework identifier e,g, 0-4, or 1-6) liked to an identity assurance framework identifier
which defines the specifics of how to derive the LoA.(See section which defines the specifics of how to derive the LoA.(See section
3.1, 3.2, 3.3 and 3.4) 3.1, 3.2, 3.3 and 3.4)
Access policies are complex and subject to change over time. For Access policies are complex and subject to change over time. For
this reason, policies MUST be identified by reference rather than this reason, policies MUST be identified by reference rather than
inclusion of the actual policy with the data. inclusion of the actual policy with the data so the policy change can
be implemented without updating the data. (See section 3.4.1)
Access to the plain text of the content MUST only be provided after Access to the plaintext of the content MUST only be provided after
the recipient has either provided suitable valid attributes to the the recipient has either provided suitable valid attributes to the
PDEP or the PDEP was able to find attributes about recipient directly PDEP or the PDEP was able to find attributes about recipient directly
from a PIP, to satisfy the policy as defined by the sender (See from a PIP, to satisfy the policy as defined by the sender (See
section 2.1.1) section 3.1 3.2, 3.3, 3.4.1, 3.5)
The sender MUST be provided with a list of policies applicable to The sender MUST be provided with a list of policies applicable to
content they create and scoped to their current role i.e. .what tasks content they create and scoped to their current role i.e. what tasks
they are currently assigned to deliver(see scenarios 3.1, 3.2, 3.3). they are currently assigned to deliver(see scenarios 3.1, 3.2, 3.3).
The specifics of the access control policy used by the PDEP MUST be The specifics of the access control policy used by the PDEP MUST be
abstracted from both the sender and recipients i.e. the DR MUST NOT abstracted from both the sender and recipients i.e. the DR MUST NOT
make the access control decision or need specifics of the access make the access control decision or need specifics of the access
policy(see scenarios 3.1, 3.2, 3.3 and 3.4). policy(see scenarios 3.1, 3.2, 3.3 and 3.4).
Content consumers DR MUST receive authenticated attributes of the Content consumers DR MUST receive authenticated attributes of the
identity of the creator, the level of identity assurance of the identity of the creator, the level of identity assurance of the
creator and the cryptographic fingerprint of the original content so creator and the cryptographic fingerprint of the original content so
skipping to change at page 45, line 44 skipping to change at page 51, line 26
content consumer and their environment. content consumer and their environment.
The PDEP MUST be stateless for processing policy requests from The PDEP MUST be stateless for processing policy requests from
content creators and consumers with respect to any instance of content creators and consumers with respect to any instance of
protected content. It MUST be possible to have multiple instances of protected content. It MUST be possible to have multiple instances of
a PDEP service and load balance requests across all instances of the a PDEP service and load balance requests across all instances of the
service transparently to the client and not require synchronization service transparently to the client and not require synchronization
of state about requests between instances of the service. of state about requests between instances of the service.
A PDEP MUST be capable of generating audit events associated with A PDEP MUST be capable of generating audit events associated with
access to protected content. access to protected content using policy defined by the PAP.
5.1.1 Email Specific General Requirements 5.1.1 Email Specific General Requirements
It MUST be possible for domains to publish keys for boundary It MUST be possible for domains to publish keys and attributes about
inspection agents. This allows senders to pre-authorize these agents the boundary inspection agents. This allows senders to pre-authorize
for access to the message. It MUST be possible for boundary the inspection agents of recipients for access to the message. It
inspection agents to request access to protected messages which have MUST be possible for boundary inspection agents to request access to
not been preauthorized by the sender. protected messages which have not been preauthorized by the sender.
It MUST be possible for MTAs to request access to protected messages It MUST be possible for MTAs to request access to protected messages
which have not been preauthorized by the sender (see section 3.5). which have not been preauthorized by the sender (see section 3.5).
5.2. Basic Policy Requirements 5.2. Basic Policy Requirements
The use of Basic Policy MUST be backwards compatible with existing The use of Basic Policy MUST be backwards compatible with existing
S/MIME. A sender's agent MAY discover some recipient's certificates S/MIME. A sender's agent MAY discover some recipient's certificates
and create recipient info structures using the existing standard and create recipient info structures using the existing standard
(unless specifically forbidden by the selected policy). A sender's (unless specifically forbidden by the selected policy). A sender's
agent MAY elect to use this mechanism for recipients for whom keys agent MAY elect to use this mechanism for recipients for whom keys
cannot be discovered. cannot be discovered.
One Basic Policy is to be defined by this work. The Basic to map to One Basic Policy is to be defined by this work. The Basic to map to
NIST 800-63-1. This process does not preclude other Basic Policies NIST 800-63-1. This process does not preclude other Basic Policies
to be defined by other groups or even within the context of the to be defined by other groups or even within the context of the
IETF. IETF.
When using Basic Policy, the sending agent MUST define which basic When using Basic Policy, the sending agent MUST define which basic
policy and the list of recipients. policy is required and the list of recipients.
Basic policy MUST support multiple levels of identity assurance. The Basic policy MUST support multiple levels of identity assurance. The
levels of identity assurance MUST map to an existing identity levels of identity assurance MUST map to an existing identity
authentication assurance framework e.g. to NIST 800-63-1 or authentication assurance framework e.g. to NIST 800-63-1 or
equivalent. need rewording to multiple basic policies equivalent.
A sender using Basic policy MUST be able to send protected messages A sender using Basic policy MUST be able to send protected messages
without discovering any recipient's encryption key. without discovering any recipient's encryption key.
Using basic policy MUST NOT require bilateral agreements between Using basic policy MUST NOT require bilateral agreements between
sender and recipients a priori to sending the message. sender and recipients a priori to sending the message.
5.2.1 Email Specific Basic Policy Requirements 5.2.1 Email Specific Basic Policy Requirements
The use of Basic Policy MUST be backwards compatible with existing The use of Basic Policy MUST be backwards compatible with existing
S/MIME. S/MIME.
A sender's agent MAY discover some recipient's certificates and A sender's agent MAY discover some recipient's certificates and
create recipient info structures as per the existing S/MIME standard create recipient info structures as per the existing S/MIME standard
and elect to use the new mechanism for recipients it cannot discover and elect to use the new mechanism for recipients it cannot discover
keys for rather than remove the recipient's without certificates. keys for rather than remove the recipient's without certificates.
5.3. Advanced Policy Requirements 5.3. Advanced Policy Requirements
A basic policy MAY be combined with advanced policies
It MUST be possible to apply one or more Advanced Policies to a It MUST be possible to apply one or more Advanced Policies to a
protected content. Where 2 or more policies are applied to protected protected content. Where 2 or more policies are applied to protected
content, the logical relationship between the policies MUST also be content, the logical relationship between the policies MUST also be
expressed i.e. are the policies a logical AND or a logical OR. (See expressed i.e. are the policies a logical AND or a logical OR. (See
section 3.3) section 3.3)
An advanced policy MAY require attributes about: An advanced policy MAY require attributes about:
o The content consumer o The content consumer
o The device the content consumer is using o The device the content consumer is using
o The environment of the device is attempting to access the o The environment of the device is attempting to access the
protected content from protected content from
o The content being accessed
Advances policy MUST support an extensible list of obligations on the Advances policy MUST support an extensible list of obligations on the
content creator where use of the policy requires some specific action content creator where use of the policy requires some specific action
on the part of the content creator e.g. sign content with 2 factor on the part of the content creator e.g. sign content with 2 factor
smart card and/or that the signature is legally binding, or the smart card and/or that the signature is legally binding, or the
message needs to be verified for an extended period(see scenarios 3.3 message needs to be verified for an extended period(see scenarios 3.3
and 3.4). and 3.4).
Advanced policies must support the ability to verify the content for Advanced policies must support the ability to verify the content for
an extended period (10 or more years) an extended period (10 or more years)
skipping to change at page 50, line 6 skipping to change at page 57, line 4
mail scanning methods in place. For these reasons recipient mail scanning methods in place. For these reasons recipient
processing systems need to implement the following counter-measures: processing systems need to implement the following counter-measures:
1) The pointer to the PDEP MUST be checked against some policy 1) The pointer to the PDEP MUST be checked against some policy
before attempting to query the PDEP for a policy decision. 2) Care before attempting to query the PDEP for a policy decision. 2) Care
MUST be taken when processing the responses from a PDEP check that MUST be taken when processing the responses from a PDEP check that
they are well-formed and meet local policy before using the they are well-formed and meet local policy before using the
responses. responses.
Editorial Comments Editorial Comments
[anchor21] JLS: Are these really the terms that we want to be using?
I normally use data origination rather than
authenticated. It would be assumed that the data
origination is being attested to by a middle man for a
sender w/o signature capability rather than
authentication being a correct term.
[anchor22] JLS: We need to talk about what operation you are getting
this level of assurance for. and who you are
authenticating to.
[anchor23] JLS: Same text should apply for senders?
[anchor24] JLS: What does assurance level mean here? Are we talking
about security levels or authentication levels or
something else? Are levels required to define a set of
requirements. I.e. An assurance level defines:
Authentication requirements, confidentiality requirements
(other).
Appendix A. References Appendix A. References
A.1. Normative References A.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2634] Hoffman, P. Ed., "Enhanced Security Services for S/MIME", [RFC2634] Hoffman, P. Ed., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999. RFC 2634, June 1999.
[RFC3198] Westerinen et. al., "Terminology for Policy Based [RFC3198] Westerinen et. al., "Terminology for Policy Based
Management", November 2001. Management", November 2001.
skipping to change at line 2241 skipping to change at page 59, line 26
Fixed multiple document nits from Jim Schaad Fixed multiple document nits from Jim Schaad
Need a paRAGRAPH on namespaces to deal with SAML attributes of Need a paRAGRAPH on namespaces to deal with SAML attributes of
different names with same semantics different names with same semantics
Don't use a proxyf5 tls offload. Define a proxy in arch Don't use a proxyf5 tls offload. Define a proxy in arch
Made changes from XACML TC to better align terminology Made changes from XACML TC to better align terminology
Cleaned up integrity scenario Cleaned up integrity scenario
Merged the two vocabulary sections into a single section
Added LOA for key exchange
Added the forward proxy to the architecture
addressed [anchor21] comment by clarifying text in paragraph 1.2
Addressed [anchor22] comment by clarifying text in paragraph 2.4
Addresses [anchor23] comments by clarifying text in section 4.
Addresses [anchor24] comment by clarifying text in section 3.
Completed the scalable policy decision making scenario (3.10)
 End of changes. 99 change blocks. 
417 lines changed or deleted 621 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/