< draft-ietf-smime-seclabel-03.txt		draft-ietf-smime-seclabel-04.txt >
	S/MIME Working Group Weston Nicolls		A new Request for Comments is now available in online RFC libraries.
	INTERNET-DRAFT Telenisus Corporation
	Expires July, 2001 January 2001
	Implementing Company Classification Policy
	with the S/MIME Security Label
	<draft-ietf-smime-seclabel-03.txt>
	Status of this memo
	This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of [RFC2026].
	Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other groups
	may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months and
	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
	them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	Copyright (C) The Internet Society (2001). All Rights Reserved.
	1. Introduction
	This document discusses how company security policy for data classification
	can be mapped to the S/MIME security label. Actual policies from 3 companies
	are used to provide worked examples.
	Security labels are an optional security service for S/MIME. A security label
	is a set of security information regarding the sensitivity of the content
	that is protected by S/MIME encapsulation. A security label can be included
	in the signed attributes of any SignedData object. A security label attribute
	may be included in either the inner signature, outer signature, or both.
	The syntax and processing rules for security labels are described in [ESS].
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT','SHOULD',
	'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be
	interpreted as described in [MUSTSHOULD].
	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
	'subscribe' in the body of the message. Also, there is a Web site for the
	mailing list at <http://www.imc.org/ietf-smime>.
	1.1 Information Classification Policies
	Information is an asset, but not all information has the same value for a
	business. Not all information needs to be protected as strongly as other
	information.
	Research and development plans, marketing strategies and manufacturing quality
	specifications developed and used by a company provide competitive advantage.
	This type of information needs stronger protective measures than other
	information, which if disclosed or modified, would cause moderate to severe
	damage to the company.
	Other types of information such as internal organization charts, employee lists
	and policies may need little and no protective measures based on value the
	organization places on it.
	A corporate information classification policy defines how its information assets
	are to be protected. It provides guidance to employees on how to classify
	information assets. It defines how to label and protect an asset based on its
	classification and state (e.g. facsimile, electronic transfer, storage,
	shipping, etc.).
	1.2 Access Control and Security Labels
	"Access control" is a means of enforcing authorizations. There are a variety of
	access control methods that are based on different types of policies and rely on
	different security mechanisms.
	- Rule based access control is based on policies that can be algorithmically
	expressed.
	- Identity based access control is based on a policy which applies explicitly
	to an individual person or host entity, or to a defined group of such entities.
	Once identity has been authenticated, if the identity is verified to be on the
	access list, then access is granted.
	- Rank base access control is based on a policy of hierarchical positions in an
	organization. It is based on who you are in the company structure. A rank-based
	policy would define what information that the position of Partner or Senior
	Consultant could access.
	- 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.
	The role-based policy would define what information that the role of Database
	Administrator, Network Administrator, Mailroom Clerk or Purchaser could access.
	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
	information. When processing an S/MIME encapsulated message, the sensitivity
	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
	content.
	An S/MIME security label may be included as a signed attribute in the inner
	(or only) signature or the outer signature. In the case of a triple-wrapped
	message as defined in RFC 2634, the inner signature would be used for access
	control decisions related to the plaintext original content, while the outer
	signature would be used for access control decisions related to the encrypted
	message.
	1.3 User Authorizations
	Users need to be granted authorizations to access information that has been
	classified by an authority. The sending and receiving agents need to be able to
	securely determine the user's authorizations for access control processing.
	[X.509] and the Internet profile for X.509 certificates [CERTCRL] do not define
	the means to represent and convey authorizations in a certificate.
	[X.501] defines how to represent authorization in the form of a clearance
	attribute. The clearance attribute identifies the security policy in force to
	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
	Attribute Certificate and a Certificate extension field (e.g., within the
	subjectDirectoryAttribute extension).
	[AC509] defines a profile of X.509 Attribute Certificate (AC) suitable for use
	with authorization information within Internet Protocols. One of the defined
	attributes is Clearance, which carries clearance (security labeling) information
	about the AC owner. The syntax for Clearance is imported from [X.501].
	2. Developed Examples
	2.1 Classification Policies
	The following describes the information classification policies in effect at 3
	companies.
	2.1.1 Amoco Corporation
	The description for the Amoco information classification policy was taken from
	the Amoco Computer Security Guidelines. Amoco classifies its information assets
	based on confidentiality and integrity and defines 3 hierarchical
	classifications for each. The confidentiality and integrity polices are
	independent, so either or both may be applied to the information. Amoco also
	defines an availability classification for time critical information.
	HIGHLY CONFIDENTIAL - Information whose unauthorized disclosure will cause the
	company severe financial, legal or reputation damage. Examples: Certain
	acquisitions, bid economics, negotiation strategies.
	CONFIDENTIAL - Information whose unauthorized disclosure may cause the company
	financial, legal, or reputation damage. Examples: Employee Personnel & Payroll
	Files, some interpreted Exploration Data.
	GENERAL - Information that, because of its personal, technical, or business
	sensitivity is restricted for use within the company. Unless otherwise
	classified, all information within Amoco is in this category.
	MAXIMUM - Information whose unauthorized modification and destruction will cause
	the company severe financial, legal, or reputation damage.
	MEDIUM - Information whose unauthorized modification and destruction may cause
	the company financial, legal, or reputation damage. Examples: Electronic Funds,
	Transfer, Payroll, and Commercial Checks
	MINIMUM - Although an error in this data would be of minimal consequence, this
	is still important company information and therefore will require some minimal
	controls to ensure a minimal level of assurance that the integrity of the data
	is maintained. This applies to all data that is not placed in one of the above
	classifications. Examples: Lease Production Data, Expense Data, Financial Data,
	and Exploration Data.
	CRITICAL - It is important to assess the availability requirements of data,
	applications and systems. A business decision will be required to determine the
	length of unavailability that can be tolerated prior to expending additional
	resources to ensure the information availability that is required. Information
	should be labeled "CRITICAL" if it is determined that special procedures should
	be used to ensure its availability.
	2.1.2 Caterpillar, Inc.
	The description for the Caterpillar information classification policy is taken
	from the Caterpillar Information Protection Guidelines. Caterpillar classifies
	its information assets based on confidentiality and defines 4 hierarchical
	classifications.
	Caterpillar Confidential Red - Provides a significant competitive advantage.
	Disclosure would cause severe damage to operations. Relates to or describes a
	long-term strategy or critical business plans. Disclosure would cause regulatory
	or contractual liability. Disclosure would cause severe damage to our reputation
	or the public image. Disclosure would cause a severe loss of market share or the
	ability to be first to market. Disclosure would cause a loss of an important
	customer, shareholder, or business partner. Disclosure would cause a long-term
	or severe drop in stock value. Strong likelihood somebody is seeking to acquire
	this information.
	Caterpillar Confidential Yellow - Provides a competitive advantage. Disclosure
	could cause moderate damage to the company or an individual. Relates to or
	describes an important part of the operational direction of the company over
	time. Important technical or financial aspects of a product line or a business
	unit. Disclosure could cause a loss of Customer or Shareholder confidence.
	Disclosure could cause a temporary drop in stock value. A likelihood that
	somebody could seek to acquire this information.
	Caterpillar Confidential Green - Might provide a business advantage over those
	who do not have access to the same information. Might be useful to a competitor.
	Not easily identifiable by inspection of a product. Not generally known outside
	the company or available from public sources. Generally available internally.
	Little competitive interest.
	Caterpillar Public - Would not provide a business or competitive advantage.
	Routinely made available to interested members of the General Public. Little or
	no competitive interest.
	2.1.3 Whirlpool Corporation
	The description for the Whirlpool information classification policy is taken
	from the Whirlpool Information Protection Policy. Whirlpool classifies its
	information assets based on confidentiality and defines 2 hierarchical
	classifications. The policy states that:
	"All information generated by or for Whirlpool, in whatever form, written,
	verbal, or electronic, is to be treated as WHIRLPOOL INTERNAL or WHIRLPOOL
	CONFIDENTIAL. Classification of information in either category depends on its
	value, the impact of unauthorized disclosure, legal requirements, and the manner
	in which it needs to be used by the company. Some WHIRLPOOL INTERNAL
	information may be authorized for public release."
	WHIRLPOOL CONFIDENTIAL - A subset of Whirlpool Internal information, the
	unauthorized disclosure or compromise of which would likely have an adverse
	impact on the company's competitive position, tarnish its reputation, or
	embarrass an individual. Examples: Customer, financial, pricing, or personnel
	data; merger/acquisition, product, or marketing plans; new product designs,
	proprietary processes and systems.
	WHIRLPOOL INTERNAL - All forms of proprietary information originated or owned by
	Whirlpool, or entrusted to it by others. Examples: Organization charts,
	policies, procedures, phone directories, some types of training materials.
	WHIRLPOOL PUBLIC - Information officially released by Whirlpool for widespread
	public disclosure. Example: Press releases, public marketing materials,
	employment advertising, annual reports, product brochures, the public web site,
	etc.
	The policy also states that privacy markings are allowable. Specifically:
	For WHIRLPOOL INTERNAL, additional markings or caveats are optional at the
	discretion of the information owner.
	For WHIRLPOOL CONFIDENTIAL, add additional marking or caveats as necessary to
	comply with regulatory or heightened security requirements. Examples: MAKE NO
	COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT,
	DISTRIBUTION LIMITED TO ____, COVERED BY A NON-ANALYSIS AGREEMENT.
	2.2 S/MIME Classification Label Organizational Examples
	[ESS] defines the ESSSecurityLabel syntax and processing rules. This section
	builds upon those definitions to define detailed example policies.
	2.2.1 Security Label Components
	The examples are detailed using the various components of the eSSSecurity Label
	syntax.
	2.2.1.1 Security Policy Identifier
	A security policy is a set of criteria for the provision of security services.
	The eSSSecurityLabel security-policy-identifier is used to identify the security
	policy in force to which the security label relates. It indicates the semantics
	of the other security label components.
	For the example policies, the following security policy object identifiers are
	defined:
	id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs-9(9) 16 }
	id-tsp OBJECT IDENTIFIER ::= { id-smime 7 }
	id-tsp-TEST-Amoco OBJECT IDENTIFIER ::= { id-tsp 1 }
	id-tsp-TEST-Caterpillar OBJECT IDENTIFIER ::= { id-tsp 2 }
	id-tsp-TEST-Whirlpool OBJECT IDENTIFIER ::= { id-tsp 3 }
	2.2.1.2 Security Classification
	The security classification values and meanings are defined by the governing
	company policies. The security-classification values defined are hierarchical
	and do not use integers 0 through 5.
	Amoco-SecurityClassification ::= INTEGER {
	amoco-general (6),
	amoco-confidential (7),
	amoco-highly-confidential (8) }
	Caterpillar-SecurityClassification ::= INTEGER {
	caterpillar-public (6),
	caterpillar-green (7),
	caterpillar-yellow (8),
	caterpillar-red (9) }
	Whirlpool-SecurityClassification ::= INTEGER {
	whirlpool-public (6),
	whirlpool-internal (7),
	whirlpool-confidential (8) }
	2.2.1.3 Privacy Mark
	Privacy marks are specified the Whirlpool policy. The policy provides examples
	of possible markings but others can be defined by users as necessary (though no
	guidance is given). The Whirlpool policy provides the following examples:
	MAKE NO COPIES, THIRD PARTY CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT,
	DISTRIBUTION LIMITED TO ____, and COVERED BY A NON-ANALYSIS AGREEMENT.
	The Amoco policy does not identify any privacy marks but the classification
	labels defined for availability and integrity would be most appropriately
	displayed here. The CRITICAL, MAXIMUM, MEDIUM, and MINIMUM labels are examples
	of information classifications that are not used for access control.
	In general, the privacy marks should provide brief but clear direction to the
	user on how to handle the information.
	2.2.1.4 Security Categories
	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
	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 when necessary to provide identifiable proprietary information more
	granular access control. A category can be based organizationally or by project
	(i.e., Legal Only or Project Vallor).
	2.2.1.4.1 Syntax
	Security categories are represented in the RFC 2634 ESSSecurityLabel
	(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
	ub-security-categories INTEGER ::= 64
	SecurityCategory ::= SEQUENCE {
	type [0] OBJECT IDENTIFIER
	value [1] ANY DEFINED BY type -- defined by type
	One example of a SecurityCategory syntax is SecurityCategoryValues, as follows.
	When id-securityCategoryValues is present in the SecurityCategory type field,
	then the SecurityCategory value field could take the form of:
	SecurityCategoryValues ::= SEQUENCE OF UTF8String
	2.2.1.4.2 Use
	An organization will define a securityCategoryType OID representing the
	syntax for representing a security category value within their security policy.
	For the example security category syntax, a UTF8String is used to convey the
	security category value that applies to the labeled message. Access MUST be
	restricted to only those entities who are authorized to access every
	SecurityCategoryValue. Access is authorized if the ESSSecurity Label
	SecurityCategoryValue EXACTLY matches the Clearance SecurityCategoryValue.
	2.2.2 Attribute Owner Clearance
	The security clearance and category authorizations for the user are defined in
	the clearance attribute.
	2.2.2.1 Amoco User
	Clearance:
	policyId: 1 2 840 113549 1 9 16 7 1
	classList: amoco-general (6),
	amoco-confidential (7),
	amoco-highly confidential (8),
	2.2.2.2 Caterpillar User
	Clearance:
	policyId: 1 2 840 113549 1 9 16 7 2
	classList: caterpillar-public (6),
	caterpillar-confidential greeen (7),
	caterpillar-confidential yellow (8),
	caterpillar-confidential red (9)
	2.2.2.3 Whirlpool User
	Clearance:
	policyId: 1 2 840 113549 1 9 16 7 3
	classList: whirlpool-public (6),
	whirlpool-internal (7),
	whirlpool-confidential (8),
	2.2.3 Security Category Example
	This section includes an example RFC 2634 ESSSecurityLabel including the example
	Security Category syntax. This section also includes example X.501
	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.
	These examples use the id-tsp-TEST-Whirlpool OID defined
	in section 2.2.1.1. Assume that the security policy identified
	by id-tsp-TEST-Whirlpool defines one securityCategoryType OIDs as follows:
	id-tsp-TEST-Whirlpool-Categories OBJECT IDENTIFIER ::= { id-tsp 4 }
	Example ESSSecurityLabel:
	security-policy-identifier: id-tsp-3
	security-classification: 8
	privacy-mark: ATTORNEY-CLIENT PRIVILEGED INFORMATION
	security-categories: SEQUENCE OF SecurityCategory
	SecurityCategory #1
	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 6, 7, 8 are set to TRUE
	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 6, 7, 8 are set to TRUE
	securityCategories: SEQUENCE OF SecurityCategory
	SecurityCategory #1:
	type: id-tsp-4
	value: HUMAN RESOURCES USE ONLY
	2.2.4 Additional ESSSecurityLabel Processing Guidance
	An implementation issue can be the mapping of the security label values to
	displayable characters. This is an issue for users who want to develop and
	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
	of hard coding the mapping into the applications is discouraged.
	This issue is viewed as local issue for the application vendor, as the solution
	does not need to be interoperable between vendors.
	An approach is the use of a Security Policy Information File (SPIF)[ ISO15816].
	A SPIF is a construct that conveys domain-specific security policy information.
	It is a signed object to protect it from unauthorized changes and to
	authenticate the source of the policy information. It contains critical display
	information such as the text string for security classifications and security
	categories to be displayed to the user, as well as additional security policy
	information.
	Another implementation issue can be obtaining the recipient's certificate when
	sending a signed-only message with a security label. Normally the recipient's
	certificate is only needed when sending an encrypted message. Applications will
	need to be able to retrieve the recipient's certificate so that the recipient's
	clearance information is available for the access control check.
	3. Security Considerations
	All security considerations from [CMS] and [ESS] apply to applications that use
	procedures described in this document.
	A. References		RFC 3114
	[AC509] Farrell, S., Housley, R., "An Internet Attribute Certificate Profile for		Title: Implementing Company Classification Policy with
	Authorization", draft-ietf-pkix-ac509prof-05.txt.		the S/MIME Security Label
			Author(s): W. Nicolls
			Status: Informational
			Date: May 2002
			Mailbox: wnicolls@forsythesolutions.com
			Pages: 14
			Characters: 27764
			Updates/Obsoletes/SeeAlso: None
	[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630.		I-D Tag: draft-ietf-smime-seclabel-04.txt
	[ESS] Hoffman, P., Editor, "Enhanced Security Services for S/MIME", RFC 2634.		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3114.txt
	[MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement		This document discusses how company security policy for data
	Levels", RFC 2119.		classification can be mapped to the S/MIME security label. Actual
			policies from three companies provide worked examples.
	[X.501] "ITU-T Recommendation X.501: Information Technology - Open Systems		This document is a product of the S/MIME Mail Security Working Group
	Interconnection - The Directory: Models", 1993.		of the IETF.
	[X.509] "ITU-T Recommendation X.509 (1997 E): Information		This memo provides information for the Internet community. It does
	Technology - Open Systems Interconnection - The Directory: Authentication		not specify an Internet standard of any kind. Distribution of this
	Framework", June 1997.		memo is unlimited.
	[ISO15816] "Information Technology - Security Techniques - Security Information		This announcement is sent to the IETF list and the RFC-DIST list.
	Objects for Access Control", ISO/IEC FDIS 15816:2000.		Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	B. Acknowledgements		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	I would like to thank Russ Housley for helping me through the process of		To: rfc-info@RFC-EDITOR.ORG
	developing this document. I would like to thank John Pawling for his technical		Subject: getting rfcs
	assistance and guidance. I would also like to thank the good people at Amoco
	(bp), Caterpillar and Whirlpool who allowed me to use their policies as the
	real examples that make this document possible.
	C. Author's Address		help: ways_to_get_rfcs
	Weston Nicolls		Requests for special distribution should be addressed to either the
	Telenisus Corporation (formerly with Ernst & Young LLP)		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	1701 Golf Rd		specifically noted otherwise on the RFC itself, all RFCs are for
	Tower 3, Suite 600		unlimited distribution.echo
	Rolling Meadows, IL 60008		Submissions for Requests for Comments should be sent to
	(847) 871-5086		RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
	wnicolls@telenisus.com		Authors, for further information.
End of changes. 13 change blocks.
	497 lines changed or deleted		32 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/