draft-ietf-smime-seclabel-01.txt   draft-ietf-smime-seclabel-02.txt 
S/MIME Working Group Weston Nicolls S/MIME Working Group Weston Nicolls
INTERNET DRAFT Telenisus Corporation INTERNET DRAFT Telenisus Corporation
Expires in six months July 2000 Expires in six months October 2000
Implementing Company Classification Policy Implementing Company Classification Policy
with the S/MIME Security Label with the S/MIME Security Label
<draft-ietf-smime-seclabel-01.txt> <draft-ietf-smime-seclabel-02.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026]. provisions of Section 10 of [RFC2026].
This document is an Internet-Draft. Internet-Drafts are working documents This document is an Internet-Draft. Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its areas, and its working of the Internet Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working documents as groups. Note that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at line 30 skipping to change at line 30
may be updated, replaced, or obsoleted by other documents at any time. It may be updated, replaced, or obsoleted by other documents at any time. It
is inappropriate to use Internet-Drafts as reference material or to cite is inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress." them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
<<Comments are contained in angle brackets like this.>>
1. Introduction 1. Introduction
This document discusses how company security policy for data classification can This document discusses how company security policy for data classification
be mapped to the S/MIME classification label. Actual policies from 3 companies can be mapped to the S/MIME security label. Actual policies from 3 companies
are used to provide worked examples. are used to provide worked examples.
Security labels are an optional security service for S/MIME. A security label is Security labels are an optional security service for S/MIME. A security label
a set of security information regarding the sensitivity of the content that is is a set of security information regarding the sensitivity of the content
protected by S/MIME encapsulation. A security label can be included in the that is protected by S/MIME encapsulation. A security label can be included
signed attributes of any SignedData object. A security label attribute may be in the signed attributes of any SignedData object. A security label attribute
included in either the inner signature, outer signature, or both. The syntax may be included in either the inner signature, outer signature, or both.
and processing rules for security labels are described in [ESS]. The syntax and processing rules for security labels are described in [ESS].
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT','SHOULD', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT','SHOULD',
'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be
interpreted as described in [MUSTSHOULD]. interpreted as described in [MUSTSHOULD].
This draft is being discussed on the 'ietf-smime' mailing list. To join the This draft is being discussed on the 'ietf-smime' mailing list. To join the
list, send a message to <ietf-smime-request@imc.org> with the single word list, send a message to <ietf-smime-request@imc.org> with the single word
'subscribe' in the body of the message. Also, there is a Web site for the 'subscribe' in the body of the message. Also, there is a Web site for the
mailing list at <http://www.imc.org/ietf-smime>. mailing list at <http://www.imc.org/ietf-smime>.
skipping to change at line 102 skipping to change at line 100
policy would define what information that the position of Partner or Senior policy would define what information that the position of Partner or Senior
Consultant could access. Consultant could access.
- Role based access control is based on a policy of roles in an organization. - Role based access control is based on a policy of roles in an organization.
It may or may not be hierarchical. It is based on who you are in the company. It may or may not be hierarchical. It is based on who you are in the company.
The role-based policy would define what information that the role of Database The role-based policy would define what information that the role of Database
Administrator, Network Administrator, Mailroom Clerk or Purchaser could access. Administrator, Network Administrator, Mailroom Clerk or Purchaser could access.
Rule, rank and role-based access control methods can rely on a security label as Rule, rank and role-based access control methods can rely on a security label as
the security mechanism to convey the sensitivity or classification of the the security mechanism to convey the sensitivity or classification of the
information. When verifying an S/MIME encapsulated message, the sensitivity information. When processing an S/MIME encapsulated message, the sensitivity
information in the message's security label can be compared with the recipient's information in the message's security label can be compared with the recipient's
authorizations to determine if the recipient is allowed to access the protected authorizations to determine if the recipient is allowed to access the protected
content. content.
An S/MIME security label may be included as an authenticated attribute in the An S/MIME security label may be included as a signed attribute in the inner
inner (or only) signature or the outer signature. The inner signature would be (or only) signature or the outer signature. In the case of a triple-wrapped
used for access control decisions related to the plaintext original content, message as defined in RFC 2634, the inner signature would be used for access
while the outer signature would be used for access control decisions related to control decisions related to the plaintext original content, while the outer
the encrypted message. signature would be used for access control decisions related to the encrypted
message.
1.3 User Authorizations 1.3 User Authorizations
Users need to be granted authorizations to access information that has been Users need to be granted authorizations to access information that has been
classified by an authority. The sending and receiving agent need to be able to classified by an authority. The sending and receiving agents need to be able to
securely determine the user's authorizations for access control processing. securely determine the user's authorizations for access control processing.
[X.509] and the Internet profile for X.509 certificates [CERTCRL] do not define [X.509] and the Internet profile for X.509 certificates [CERTCRL] do not define
the means to represent and convey authorizations in a certificate. the means to represent and convey authorizations in a certificate.
[X.501] defines how to represent authorization in the form of a clearance [X.501] defines how to represent authorization in the form of a clearance
attribute. The clearance attribute identifies the security policy in force to attribute. The clearance attribute identifies the security policy in force to
which a list of possible classifications and security categories relates. which a list of possible classifications and security categories relates.
[X.501] also notes two means for binding the clearance to a named entity: an [X.501] also notes two means for binding the clearance to a named entity: an
skipping to change at line 251 skipping to change at line 250
Whirlpool, or entrusted to it by others. Examples: Organization charts, Whirlpool, or entrusted to it by others. Examples: Organization charts,
policies, procedures, phone directories, some types of training materials. policies, procedures, phone directories, some types of training materials.
WHIRLPOOL PUBLIC - Information officially released by Whirlpool for widespread WHIRLPOOL PUBLIC - Information officially released by Whirlpool for widespread
public disclosure. Example: Press releases, public marketing materials, public disclosure. Example: Press releases, public marketing materials,
employment advertising, annual reports, product brochures, the public web site, employment advertising, annual reports, product brochures, the public web site,
etc etc
The policy also states that privacy markings are allowable. Specifically: The policy also states that privacy markings are allowable. Specifically:
For WHIRLPOOL INTERNAL, additional markings or caveats are option at the For WHIRLPOOL INTERNAL, additional markings or caveats are optional at the
discretion of the information owner. discretion of the information owner.
For WHIRLPOOL CONFIDENTIAL, add additional marking or caveats as necessary to For WHIRLPOOL CONFIDENTIAL, add additional marking or caveats as necessary to
comply with regulatory or heightened security requirements. Examples: MAKE NO comply with regulatory or heightened security requirements. Examples: MAKE NO
COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT, COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT,
DISTRIBUTION LIMITED TO ____, COVERED BY A NON-ANALYSIS AGREEMENT. DISTRIBUTION LIMITED TO ____, COVERED BY A NON-ANALYSIS AGREEMENT.
2.2 S/MIME Classification Label Developed Examples 2.2 S/MIME Classification Label Developed Examples
[ESS] defines the ESSSecurityLabel syntax and processing rules. This section [ESS] defines the ESSSecurityLabel syntax and processing rules. This section
skipping to change at line 283 skipping to change at line 282
policy in force to which the security label relates. It indicates the semantics policy in force to which the security label relates. It indicates the semantics
of the other security label components. of the other security label components.
For the example policies, the following security policy object identifiers are For the example policies, the following security policy object identifiers are
defined: defined:
-- S/MIME Working Group Object Identifier Registry -- S/MIME Working Group Object Identifier Registry
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) 16 } pkcs(1) pkcs-9(9) 16 }
-- S/MIME Test Security Policy Arc
id-tsp OBJECT IDENTIFIER ::= { id-smime 7 } id-tsp OBJECT IDENTIFIER ::= { id-smime 7 }
-- Test Security Policies -- Test Security Policies
id-tsp-TEST-Amoco OBJECT IDENTIFIER ::= { id-tsp 1 } id-tsp-TEST-Amoco OBJECT IDENTIFIER ::= { id-tsp 1 }
id-tsp-TEST-Caterpillar OBJECT IDENTIFIER ::= { id-tsp 2 } id-tsp-TEST-Caterpillar OBJECT IDENTIFIER ::= { id-tsp 2 }
id-tsp-test-Whirlpool OBJECT IDENTIFIER ::= { id-tsp 3 } id-tsp-TEST-Whirlpool OBJECT IDENTIFIER ::= { id-tsp 3 }
2.2.1.2 Security Classification 2.2.1.2 Security Classification
The security classification values and meanings are defined by the governing The security classification values and meanings are defined by the governing
company policies. The security-classification values defined are hierarchical company policies. The security-classification values defined are hierarchical
and do not use integers 0 through 5. and do not use integers 0 through 5.
Amoco-SecurityClassification ::= { Amoco-SecurityClassification ::= {
amoco general (6), amoco general (6),
amoco confidential (7), amoco confidential (7),
skipping to change at line 316 skipping to change at line 315
caterpillar red (9) } (0..ub-integer-options) caterpillar red (9) } (0..ub-integer-options)
Whirlpool-SecurityClassification values ::= { Whirlpool-SecurityClassification values ::= {
whirlpool public (6), whirlpool public (6),
whirlpool internal (7), whirlpool internal (7),
whirlpool confidential (8) } (0..ub-integer-options) whirlpool confidential (8) } (0..ub-integer-options)
2.2.1.3 Privacy Mark 2.2.1.3 Privacy Mark
Privacy marks are specified the Whirlpool policy. The policy provides examples Privacy marks are specified the Whirlpool policy. The policy provides examples
of possible markings but other can be defined by users as necessary (though no of possible markings but others can be defined by users as necessary (though no
guidance is given). The Whirlpool policy provides the following examples: guidance is given). The Whirlpool policy provides the following examples:
MAKE NO COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT, MAKE NO COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT,
DISTRIBUTION LIMITED TO ____, and COVERED BY A NON-ANALYSIS AGREEMENT. DISTRIBUTION LIMITED TO ____, and COVERED BY A NON-ANALYSIS AGREEMENT.
The Amoco policy does not identify any privacy marks but the classification The Amoco policy does not identify any privacy marks but the classification
labels defined for availability and integrity would be most appropriately labels defined for availability and integrity would be most appropriately
displayed here. The CRITICAL, MAXIMUM, MEDIUM, MINIMUM labels are examples of displayed here. The CRITICAL, MAXIMUM, MEDIUM, and MINIMUM labels are examples
information classification that are not used for access control. of information classifications that are not used for access control.
In general, the privacy marks should provide brief but clear direction to the In general, the privacy marks should provide brief but clear direction to the
user on how to handle the information. user on how to handle the information.
2.2.1.4 Security Categories 2.2.1.4 Security Categories
Security categories or caveats are not specified to any of the sample policies. Security categories or caveats are not specified in any of the sample policies.
However, they are used in at least 2 of the companies. Though the security However, they are used in at least 2 of the companies. Though the security
categories are not defined formally in the security policies, once locally categories are not defined formally in their security policies, once locally
defined they are formal and are to be enforced. The security categories are defined they are formal and are to be enforced. The security categories are
defined when necessary to provide identifiable proprietary information more defined when necessary to provide identifiable proprietary information more
granular access control. A category can be based organizationally or by project granular access control. A category can be based organizationally or by project
(i.e., Legal Only or Project Vallor). (i.e., Legal Only or Project Vallor).
2.2.1.4.1 Syntax 2.2.1.4.1 Syntax
User specified security categories are defined using the following syntax Security categories are represented in the RFC 2634 ESSSecurityLabel
(taken and expanded from [ESS]). (to specify the sensitivity of labeled data) and X.501 Clearance attribute
(to specify an entity's authorizations) using the following syntax.
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF SecurityCategory SecurityCategories ::= SET SIZE (1..ub-security-categories) OF SecurityCategory
ub-security-categories INTEGER ::= 64 ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE { SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER <<need to get a generic SMIME OID>> type [0] OBJECT IDENTIFIER
value [1] ANY DEFINED BY type -- defined by type value [1] ANY DEFINED BY type -- defined by type
When id-securityCategoryValues is present in the SecurityCategory type field, then One example of a SecurityCategory syntax is SecurityCategoryValues, as follows.
the SecurityCategory value field will take the form of SecurityCategoryValues as
follows:
SecurityCategoryValues ::= SEQUENCE OF SecurityCategoryTagGroup
SecurityCategoryTagGroup ::= SEQUENCE { When id-securityCategoryValues is present in the SecurityCategory type field,
securityCategoryTagGroupName OBJECT IDENTIFIER, then the SecurityCategory value field could take the form of
securityCategoryTagGroup SEQUENCE OF SecurityCategoryTag} SecurityCategoryValues as follows:
SecurityCategoryTag ::= CHOICE { SecurityCategoryValues ::= SEQUENCE OF UTF8String
restrictiveBitMap [0] BIT STRING,
permissiveBitMap [1] BIT STRING,
noAccessControlBitMap [2] BIT STRING,
restrictiveEnumerated [3] SEQUENCE OF INTEGER,
permissiveEnumerated [4] SEQUENCE OF INTEGER,
noAccessControlEnumerated [5] SEQUENCE OF INTEGER}
2.2.1.4.2 Use 2.2.1.4.2 Use
An organization will define a securityCategoryTagGroupName OID representing each An organization will define a securityCategoryType OID representing the
unique group of defined security category values (i.e. SecurityCategoryTagGroup) syntax for representing a security category value within their security policy.
within their security policy. An organization can define multiple
SecurityCategoryTagGroups within their security policy. A
SecurityCategoryTagGroup MUST not include multiple definitions for a
SecurityCategoryTag CHOICE. For example, there MUST not be multiple
permissiveBitMaps defined within a single SecurityCategoryTagGroup.
The Restrictive Bit Map Tag bit string is used to convey a set of non-hierarchical For the example security category syntax, a UTF8String is used to convey the
attributes that apply to the labeled message. A bit is assigned to every security security category value that applies to the labeled message. Access MUST be
policy-defined restrictive attribute. Bits corresponding to restrictive attributes restricted to only those entities who are authorized to access every
that apply will be set to 1, otherwise bits are set to 0. Access MUST be restricted SecurityCategoryValue. Access is authorized if the ESSSecurity Label
to only those entities whose set of attributes is a subset of the attributes for SecurityCategoryValue EXACTLY matches the Clearance SecurityCategoryValue.
the receiving end. Security compartments and caveats are examples of restrictive
security attributes.
The Permissive Bit Map Tag bit string is used to convey a set of non-hierarchical 2.2.1.4.3 Security Category Example
attributes that apply to the labeled message. A bit is assigned to every security
policy-defined permissive attribute. Release markings are examples of permissive
security attributes. Bits corresponding to types or groups of entities that are
granted access to the message are set to 0, all other bits are set to 1. For
example, the label on entities to be available only to members of an
organization's Personnel Office will have the bit assigned to the Personnel
Office set to 0 and all others set to 1. A message can be accepted if the
receiving end belongs to any of the release groups in the release permission list
on the message label.
The No Access Control Bit Map Tag bit string is used to to represent security This section includes an example RFC 2634 ESSSecurityLabel including the example
category values for which no access control check is required (e.g. originator Security Category syntax. This section also includes example X.501
controlled data). Clearance attributes. One of the example Clearance attributes includes a
set of authorizations that pass the access control check for the example
ESSSecurityLabel. The other example Clearance attributes each include a set
of authorizations that fail the access control check for the example
ESSSecurityLabel.
The Restrictive Enumerated Tag non-negative integers convey a security level, a These examples use the id-tsp-TEST-Whirlpool OID defined
hierarchical security attribute. The higher the value of this attribute the in section 2.2.1.1. Assume that the security policy identified
higher the security level of the labeled message. Each of the integers that by id-tsp-TEST-Whirlpool defines one securityCategoryType OIDs as follows:
follow represent a non-hierarchical attribute that applies to the labeled
message. This is an alternative to the bit-representation in the Restrictive Bit
Map Tag. It is intended to minimize label length in cases where only a few
attributes out of a large set apply to the message. An example of attributes
enumerated by this tag are compartments. Access MUST be restricted to
only those messages whose set of attributes is a subset of the attributes for the
receiving end.
The Permissive Enumerated Tag non-negative integers convey a security level, a id-tsp-TEST-Whirlpool-Categories OBJECT IDENTIFIER ::= { id-tsp 4 }
hierarchical security attribute. The higher the value of this attribute the
higher the security level of the labeled message. Each of the integers that
follow represent a non-hierarchical attribute that applies to the labeled
message. This is an alternative to the bit-representation in the Permissive
Enumerated Tag. It is intended to minimize label length in cases where only a few
attributes out of a large set apply to the message. An example of attributes
enumerated by this tag are release permissions. A message can be accepted if the
receiving end belongs to any of the release groups in the release permission list
on the message label.
The No Accesss Control Enumerated Tage non-negative integers convey security category Example ESSSecurityLabel:
values for which no access control check is required (e.g. list of country codes).
2.2.1.4.3 Security Category Example ESSSecurityLabel:
security-policy-identifier: id-tsp-3
security-classification: 9
privacy-mark: ATTORNEY-CLIENT PRIVILEGED INFORMATION
security-categories: SEQUENCE OF SecurityCategory
<<need to an at least example for each type with a test securityCategoryTagGroupNam SecurityCategory #1
OID and sample values>> type: id-tsp-4
value: LAW DEPARTMENT USE ONLY
Example Clearance Attribute #1 (passes access control check):
Clearance:
policyId: id-tsp-3
classList BIT STRING: Bits 0, 1, 2, 9 are set to 1
securityCategories: SEQUENCE OF SecurityCategory
SecurityCategory #1
type: id-tsp-4
value: LAW DEPARTMENT USE ONLY
Example Clearance Attribute #2 (fails access control check because
SecurityCategoryValues do not match):
Clearance:
policyId: id-tsp-3
classList BIT STRING: Bits 0, 1, 2, 9 are set to 1
securityCategories: SEQUENCE OF SecurityCategory
SecurityCategory #1:
type: id-tsp-4
value: HUMAN RESOURCES USE ONLY
2.2.2 Attribute Owner Clearance 2.2.2 Attribute Owner Clearance
The security clearance and category authorizations for the user are defined in The security clearance and category authorizations for the user are defined in
the clearance attribute. the clearance attribute.
2.2.2.1 Amoco User 2.2.2.1 Amoco User
Clearance ::= SEQUENCE { Clearance ::= SEQUENCE {
policyId 1 2 840 113549 1 9 16 7 1, policyId 1 2 840 113549 1 9 16 7 1,
skipping to change at line 499 skipping to change at line 488
whirlpool public (6), whirlpool public (6),
whirlpool internal (7), whirlpool internal (7),
whirlpool confidential (8), whirlpool confidential (8),
} }
SecurityCategory ::= SEQUENCE { SecurityCategory ::= SEQUENCE {
type [0] IMPLICIT OBJECT IDENTIFIER, type [0] IMPLICIT OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type value [1] ANY DEFINED BY type
} }
<<need to complete security category with example OIDs and values>>
2.2.3 Additional ESSSecurityLabel Processing Guidance 2.2.3 Additional ESSSecurityLabel Processing Guidance
An implementation issue with the security label is the mapping of the bit string An implementation issue can be the mapping of the security label values to
to displayable characters. This is an issue for users who want to develop and displayable characters. This is an issue for users who want to develop and
retire their own classifications and categories a regular basis. Applications retire their own classifications and categories a regular basis and when the
values are encoded in non-human readable form. Applications
should provide a means for the enterprise to manage these changes. The practice should provide a means for the enterprise to manage these changes. The practice
of hard coding the mapping into the applications is discouraged. of hard coding the mapping into the applications is discouraged.
This issue is viewed as local issue for the application vendor, as the solution This issue is viewed as local issue for the application vendor, as the solution
does not need to be interoperable between vendors. does not need to be interoperable between vendors.
An approach is the use of a Security Policy Information File (SPIF)[X.sio]. A An approach is the use of a Security Policy Information File (SPIF)[X.sio]. A
SPIF is a construct that conveys domain-specific security policy information. SPIF is a construct that conveys domain-specific security policy information.
It is also a sign object to protect it from unauthorized changes and to It is a signed object to protect it from unauthorized changes and to
authenticate the source of the policy information. It contains critical display authenticate the source of the policy information. It contains critical display
information such as the text string for security classifications and security information such as the text string for security classifications and security
categories to be displayed to the user, as well as additional security policy categories to be displayed to the user, as well as additional security policy
information. information.
3. Security Considerations 3. Security Considerations
All security considerations from [CMS] and [ESS] apply to applications that use All security considerations from [CMS] and [ESS] apply to applications that use
procedures described in this document. procedures described in this document.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/